Hi Guillaume, Thank you for the prompt response. I have logged the following issue https://issues.apache.org/jira/browse/ARIES-1066
Best regards, Declan On 9 May 2013 17:49, Guillaume Nodet <[email protected]> wrote: > Yes, those are really good suggestions. Please raise JIRA issues for that. > I'm not sure yet how this is doable now, because classes are redefined in > order to get rid of the OSGi dependencies, so the container implementation > is not the only problem here. It will certainly need a modification of the > blueprint-core project. > > > > On Thu, May 9, 2013 at 2:30 PM, Declan Cox <[email protected]> wrote: > >> hi, >> I have bundle which implements a EIP route using Apache Camel. The target >> container is Apache Karaf 2.3.1 (with Aries Blueprint 1.0.0) >> >> For testing convenience the blueprint context is described in three >> context descriptors, something like this: >> >> osgi-context.xml - cm integration and service provision and >> consumption >> beans.xml - internal bean instances and service >> implementations >> camel.xml - camel context >> >> Here is what I would like to achieve: >> >> 1. I would like to use camel-test-blueprint to test the route in camel.xml >> 2. I would like to independently test bean instances in beans.xml using >> blueprint without any OSGi paraphernalia. >> >> I had a look at blueprint-noosgi and thought that this would be the >> answer I was looking for i.e., simple IoC ala spring where I could use the >> ext:property-placeholder to simulate the cm integration and provide a bean >> instance to stub out the service references in osgi-context.xml (I used >> exactly this tactic along with bean aliasing with spring DM in the past and >> it worked very well). >> >> There is a fundamental problem with this however; I cannot have both the >> core blueprint container implementation and the noosgi blueprint container >> on the classpath of my bundle project at the same time. Both containers >> have the same fully qualified name >> (org.apache.aries.blueprint.container.BlueprintContainerImpl). This is >> highly inconvenient since I would like to use camel-test-blueprint >> (transitively depends on blueprint core) and noosgi blueprint dependencies >> in the same project (both are of course at test scope but this is >> irrelevant) >> >> Is there any reason why this is organised in this way ? It would be >> better in my estimation to either have (i) a different name for the noosgi >> container variant or ideally (ii) a single container factory which allowed >> creation of either the osgi or non-osgi variants. >> >> Many thanks in advance, >> Declan >> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > >
