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 10:41:16 UTC
[jira] [Updated] (ARIES-1066) BlueprintContainerImpl type conflict
between core and noosgi
[ https://issues.apache.org/jira/browse/ARIES-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Declan Cox updated ARIES-1066:
------------------------------
Description:
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 (a) one should make the names distinct or (b) 'fold' the noosgi variant into blueprint core and provide a container factory of some kind.
I am sensible of the issue of run time container dependencies, so it would seem that (a) might be the most expedient, however (b) is the most desirable from an architectural point of view.
was:
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.
> 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
> Labels: blueprint
>
> 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 (a) one should make the names distinct or (b) 'fold' the noosgi variant into blueprint core and provide a container factory of some kind.
> I am sensible of the issue of run time container dependencies, so it would seem that (a) might be the most expedient, however (b) 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