Hi, Thanks, this is a way around it of course. Actually this issue arose when I was converting some of my bundles from Spring-dm to blueprint. With Spring DM I had the full power of Spring and the OSGi mocks and was able to organize my contexts as outlined in my first email. I wanted to post this to help nudge Aries in the right direction :) Best regards, Declan
On 10 May 2013 16:14, Charlie Mordant <[email protected]> wrote: > 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 >
