You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Aki Yoshida (Created) (JIRA)" <ji...@apache.org> on 2011/12/14 09:30:30 UTC

[jira] [Created] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
----------------------------------------------------------------------------------------------------------------------------------

                 Key: ARIES-802
                 URL: https://issues.apache.org/jira/browse/ARIES-802
             Project: Aries
          Issue Type: Bug
          Components: Blueprint
    Affects Versions: blueprint-core-0.4.1
         Environment: karaf 2.2.4
            Reporter: Aki Yoshida
             Fix For: blueprint-0.4.0


I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. 

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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
        at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
        at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
        at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
        at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet updated ARIES-802:
----------------------------------

    Fix Version/s: blueprint-core-0.3.2
    
> dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-802
>                 URL: https://issues.apache.org/jira/browse/ARIES-802
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>    Affects Versions: blueprint-core-0.4.1
>         Environment: karaf 2.2.4
>            Reporter: Aki Yoshida
>             Fix For: blueprint-0.4.0, blueprint-core-0.3.2
>
>         Attachments: patch.diff
>
>
> I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. 
> 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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

Posted by "Aki Yoshida (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204017#comment-13204017 ] 

Aki Yoshida commented on ARIES-802:
-----------------------------------

Hi Guillaume,
That would be fine too. My mind was actually torn between these two approaches :-)

Putting the reset line right in front of the register line will ensure the registry is empty before registration.

I thought, if the registry becomes dirty only when that waiting-for-the-missing-components happened in the previous time, we could empty the registry at that moment so that the registry stays clean for the next time.

Regards, aki
                
> dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-802
>                 URL: https://issues.apache.org/jira/browse/ARIES-802
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>    Affects Versions: blueprint-core-0.4.1
>         Environment: karaf 2.2.4
>            Reporter: Aki Yoshida
>             Fix For: blueprint-0.4.0
>
>         Attachments: patch.diff
>
>
> I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. 
> 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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

Posted by "Guillaume Nodet (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203699#comment-13203699 ] 

Guillaume Nodet commented on ARIES-802:
---------------------------------------

I think the reset method should be called each time before the fist call to registerComponentDefinition.
Somethig like 
{code}

                        if (missing.size() > 0) {
                            LOGGER.info("Bundle {} is waiting for namespace handlers {}", bundleContext.getBundle().getSymbolicName(), missing);
                            eventDispatcher.blueprintEvent(new BlueprintEvent(BlueprintEvent.GRACE_PERIOD, getBundleContext().getBundle(), getExtenderBundle(), missing.toArray(new String[missing.size()])));
                            return;
                        }
                        componentDefinitionRegistry.reset();
                        componentDefinitionRegistry.registerComponentDefinition(new PassThroughMetadataImpl("blueprintContainer", this));
{code}

                
> dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-802
>                 URL: https://issues.apache.org/jira/browse/ARIES-802
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>    Affects Versions: blueprint-core-0.4.1
>         Environment: karaf 2.2.4
>            Reporter: Aki Yoshida
>             Fix For: blueprint-0.4.0
>
>         Attachments: patch.diff
>
>
> I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. 
> 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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/ARIES-802
>             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 0.4.1-snapshot. 
> 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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (ARIES-802) dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component

Posted by "Aki Yoshida (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ARIES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aki Yoshida updated ARIES-802:
------------------------------

    Attachment: patch.diff

aries trunk diff for
M       blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java

                
> dependent restart causes ComponentNameAlreadyInUseException: Name 'blueprintContainer' is already in use by a registered component
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARIES-802
>                 URL: https://issues.apache.org/jira/browse/ARIES-802
>             Project: Aries
>          Issue Type: Bug
>          Components: Blueprint
>    Affects Versions: blueprint-core-0.4.1
>         Environment: karaf 2.2.4
>            Reporter: Aki Yoshida
>             Fix For: blueprint-0.4.0
>
>         Attachments: patch.diff
>
>
> I saw this problem several months ago. This problem still occurs in the current trunk 0.4.1-snapshot. 
> 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(ComponentDefinitionRegistryImpl.java:88)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:286)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:241)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[10:org.apache.aries.blueprint:0.4.1.SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_24]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_24]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_24]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662)[: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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira