aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <>
Subject [jira] [Resolved] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
Date Wed, 25 Jul 2012 07:37:43 GMT


Guillaume Nodet resolved ARIES-802.

       Resolution: Fixed
    Fix Version/s: blueprint-core-1.0.1
         Assignee: Guillaume Nodet
> dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer'
is already in use by a registered component
> ----------------------------------------------------------------------------------------------------------------------------------
>                 Key: ARIES-802
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>    Affects Versions: blueprint-core-0.4.1
>         Environment: karaf 2.2.4
>            Reporter: Aki Yoshida
>            Assignee: Guillaume Nodet
>             Fix For: blueprint-0.4.0, blueprint-core-0.3.2, blueprint-core-1.0.1
>         Attachments: patch.diff
> I saw this problem several months ago. This problem still occurs in the current trunk
> I have two bundles A and B running and A depends on B. In my concrete case, A is an application
scenario bundle depending on B the cxf bundle.
> Initially, both are running and have status Active. When I stop B, A goes to status GracePeriod.
When I start B again, A is started but does not come back to status Active but goes to status
"Failure" with the following error:
> 2011-12-14 01:12:49,755 | ERROR | rint Extender: 2 | BlueprintContainerImpl         
 | container.BlueprintContainerImpl
>   362 | 10 - org.apache.aries.blueprint - 0.4.1.SNAPSHOT | Unable to start blueprint
container for bundle tmp.test-osgi-cxf-provider-bp
> org.apache.aries.blueprint.ComponentNameAlreadyInUseException: Name 'blueprintContainer'
is already in use by a registered component
>         at org.apache.aries.blueprint.parser.ComponentDefinitionRegistryImpl.registerComponentDefinition([10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun([10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun([:1.6.0_24]
>         at[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301([:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask([:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$[:1.6.0_24]
>         at[:1.6.0_24]
> The cause of this problem seems to be that this bundle's blueprint container's component
definition map is not cleared up prior to getting restarted. This calls ComponentRegistryImpl's
registerComponentDefinition and this method checks if the same named component is already
in the map. 
> I added a line of code to clear up the definition map and this made the bundle start
and its status go to Active.
> Please take a look at the attached file.
> Regards, aki

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message