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/
