Re: Pax CDI and Camel...testing...

2016-09-06 Thread Brad Johnson
It makes me wonder if since this is still in RC if the @OSGiServiceProvider and @OSGiService shouldn't just be removed. Or, at the very least, market as deprecated. On Tue, Sep 6, 2016 at 10:53 AM, Brad Johnson wrote: > A very cool. Thank you. I'll give that a

Re: Pax CDI and Camel...testing...

2016-09-06 Thread Brad Johnson
A very cool. Thank you. I'll give that a shot. And I agree with 100% that having to specify a start order is a recipe for spaghetti and circular dependencies that could make you pull your hair out. On Mon, Sep 5, 2016 at 2:47 PM, Guillaume Nodet wrote: > Yeah, that looks

Re: Pax CDI and Camel...testing...

2016-09-03 Thread Ranx0r0x
While I find this less than ideal, until I get to know how CDI in general and Pax CDI specifically work, I've modified my DatastoreImpl class to have a @Produces annotation with a "factory" method for lack of a better name. While this facilitates testing locally and lets me inject the interface

Re: Pax CDI and Camel...testing...

2016-09-03 Thread Brad Johnson
While not ideal, if I just remove the @OsgiService from the unit test it injects because it is within the same bundle. I'll likely have to use a different testing mechanism to get the provider/service injection to work. I've also added this to make sure the service is exported the way I want