Hi, I faced the same problem and used Camel spring with mocked service duplicating the blueprint config for my Unit-tests. It's not optimal but did the trick.
Regards, 2013/5/10 Declan Cox <[email protected]> > 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/ >> >> > -- Cordialement, Charlie Mordant
