You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Declan Cox (JIRA)" <ji...@apache.org> on 2013/05/10 00:01:16 UTC

[jira] [Created] (ARIES-1066) BlueprintContainerImpl type conflict between core and noosgi

Declan Cox created ARIES-1066:
---------------------------------

             Summary: BlueprintContainerImpl type conflict between core and noosgi
                 Key: ARIES-1066
                 URL: https://issues.apache.org/jira/browse/ARIES-1066
             Project: Aries
          Issue Type: Improvement
          Components: Blueprint
    Affects Versions: blueprint-noosgi-1.0.0
            Reporter: Declan Cox


The type org.apache.aries.blueprint.container.BlueprintContainerImpl exists as a type in both blueprint core and blueprint noosgi. The latter is intended to provide ex-OSGi-container capability in the style of a spring container. 
This is useful in unit test contexts where the osgi details such as service references and cm integration can be quite nicely substituted. However the fact that these containers have the same fully qualified name is an issue especially when testing Camel routes using the camel-test-blueprint API which depends on blueprint core, meaning you end up with a classpath conflict.

In any case it is a dodgy practice that these distinct containers should have the same fully qualified type name. 

Either (i) one should make the names distinct or (ii) 'fold' the noosgi variant into blueprint core and provide a container factory of some kind.
I am sensible of the issue runtime container dependencies, so it would seem that (i) might be the most expedient, however (ii) is the most desirable from an architectural point of view.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira