[
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
