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 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 one of the big limitation of pax-cdi 1.0.0.RC1.
>> The problem is that the bean validation will fail if the service is not
>> available in the OSGi registry.
>> This implies that the bundle have to be started in the correct order,
>> which imho is a REALLY bad idea.
>>
>> In order to fix this problem along with some other problems, I've defined
>> a new set of annotations which is available in 1.0.0-SNAPSHOT (not released
>> yet).  Those are modeled closely to the OSGi DS semantics.
>>
>> So try with
>> @Inject @Service  private DataStore datastore;
>> on on the service implementation:
>> @Service @Component
>>   public class DevelopmentDataStoreImpl implements DataStore {
>>
>> If you have any problem, let me know and I'll fix it.
>>
>>
>> On Sat, Sep 3, 2016 at 5:50 PM, Brad Johnson <
>> brad.john...@mediadriver.com> wrote:
>>
>>> I've been using the 2.17 update of Camel that more closely integrates
>>> CDI 1.2 and specifically Pax CDI.  I'm quite impressed with and look
>>> forward to using it in the years ahead.  I've used blueprint for quite
>>> awhile and while it works well enough the CDI simply makes development much
>>> easier and testing is a snap.
>>>
>>> One problem I've run into is with the CDI testing framework.  Within
>>> bundle tests or even bundles listed as dependencies work just fine.  But
>>> when I try to use the @OsgiServiceProvider and @OsgiService I run into some
>>> problems.  It may simply be that the regular CDI runner with Weld isn't
>>> appropriate for testing service export and import.
>>>
>>> From what I can tell I'm either missing a library dependency or the CDI
>>> test even within bundle will not respect the pick up or use the annotations.
>>>
>>> The @Inject in this unit test shows a squiggly yellow underline
>>> indicating it can't find anything to inject.
>>>
>>> @RunWith(CamelCdiRunner.class)
>>> public class DevelopmentDataStoreTest {
>>>
>>> @Inject
>>> @OsgiService
>>> private DataStore datastore;
>>>
>>> In the same bundle I have am Impl of the DataStore interface that looks
>>> like this:
>>>
>>> @Singleton
>>> @OsgiServiceProvider
>>> public class DevelopmentDataStoreImpl implements DataStore {
>>>
>>> I've tried a number of different permutations such as adding a
>>> dynamic=true to the OsgiService annotation.
>>>
>>> The stack trace on the test seems to indicate that it understand what it
>>> is I want to do but I don't have something right about it (italics are
>>> mine).
>>>
>>> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers
>>> @OsgiService
>>>   at injection point [BackedAnnotatedField] @Inject @OsgiService private
>>> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>>>   at org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTes
>>> t.datastore(DevelopmentDataStoreTest.java:0)
>>> WELD-001475: *The following beans match by type, but none have matching
>>> qualifiers:*
>>> *  - Managed Bean [class
>>> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with
>>> qualifiers [@OsgiServiceProvider @Any]*
>>>
>>> Italics are mine. So something is off about my annotations. Should the
>>> OsgiServiceProvider be scoped differently?  For in bundle testing like this
>>> I could use @Named("dataStore") and inject it that way.
>>>
>>>
>>> My imports look like the following:
>>> 
>>> javax.enterprise
>>> cdi-api
>>> ${cdi.version}
>>> 
>>> 
>>> org.ops4j.pax.cdi
>>> pax-cdi-api
>>> 1.0.0.RC1
>>> 
>>> 
>>> org.apache.camel
>>> camel-cdi
>>> ${camel.version}
>>> 2.17.3
>>> 
>>>
>>> 
>>> 
>>> org.apache.camel
>>> camel-test-cdi
>>> ${camel.version}
>>> test
>>> 
>>>
>>> Any help is appreciated.
>>>
>>> --
>>> --
>>> --
>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "OPS4J" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ops4j+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OPS4J" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/ops4j/YB43ObFXnPo/unsubscribe.
>> To unsubscribe from this group and all its

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 one of the big limitation of pax-cdi 1.0.0.RC1.
> The problem is that the bean validation will fail if the service is not
> available in the OSGi registry.
> This implies that the bundle have to be started in the correct order,
> which imho is a REALLY bad idea.
>
> In order to fix this problem along with some other problems, I've defined
> a new set of annotations which is available in 1.0.0-SNAPSHOT (not released
> yet).  Those are modeled closely to the OSGi DS semantics.
>
> So try with
> @Inject @Service  private DataStore datastore;
> on on the service implementation:
> @Service @Component
>   public class DevelopmentDataStoreImpl implements DataStore {
>
> If you have any problem, let me know and I'll fix it.
>
>
> On Sat, Sep 3, 2016 at 5:50 PM, Brad Johnson  > wrote:
>
>> I've been using the 2.17 update of Camel that more closely integrates CDI
>> 1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to
>> using it in the years ahead.  I've used blueprint for quite awhile and
>> while it works well enough the CDI simply makes development much easier and
>> testing is a snap.
>>
>> One problem I've run into is with the CDI testing framework.  Within
>> bundle tests or even bundles listed as dependencies work just fine.  But
>> when I try to use the @OsgiServiceProvider and @OsgiService I run into some
>> problems.  It may simply be that the regular CDI runner with Weld isn't
>> appropriate for testing service export and import.
>>
>> From what I can tell I'm either missing a library dependency or the CDI
>> test even within bundle will not respect the pick up or use the annotations.
>>
>> The @Inject in this unit test shows a squiggly yellow underline
>> indicating it can't find anything to inject.
>>
>> @RunWith(CamelCdiRunner.class)
>> public class DevelopmentDataStoreTest {
>>
>> @Inject
>> @OsgiService
>> private DataStore datastore;
>>
>> In the same bundle I have am Impl of the DataStore interface that looks
>> like this:
>>
>> @Singleton
>> @OsgiServiceProvider
>> public class DevelopmentDataStoreImpl implements DataStore {
>>
>> I've tried a number of different permutations such as adding a
>> dynamic=true to the OsgiService annotation.
>>
>> The stack trace on the test seems to indicate that it understand what it
>> is I want to do but I don't have something right about it (italics are
>> mine).
>>
>> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers
>> @OsgiService
>>   at injection point [BackedAnnotatedField] @Inject @OsgiService private
>> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>>   at org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTes
>> t.datastore(DevelopmentDataStoreTest.java:0)
>> WELD-001475: *The following beans match by type, but none have matching
>> qualifiers:*
>> *  - Managed Bean [class
>> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with
>> qualifiers [@OsgiServiceProvider @Any]*
>>
>> Italics are mine. So something is off about my annotations. Should the
>> OsgiServiceProvider be scoped differently?  For in bundle testing like this
>> I could use @Named("dataStore") and inject it that way.
>>
>>
>> My imports look like the following:
>> 
>> javax.enterprise
>> cdi-api
>> ${cdi.version}
>> 
>> 
>> org.ops4j.pax.cdi
>> pax-cdi-api
>> 1.0.0.RC1
>> 
>> 
>> org.apache.camel
>> camel-cdi
>> ${camel.version}
>> 2.17.3
>> 
>>
>> 
>> 
>> org.apache.camel
>> camel-test-cdi
>> ${camel.version}
>> test
>> 
>>
>> Any help is appreciated.
>>
>> --
>> --
>> --
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to ops4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "OPS4J" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/ops4j/YB43ObFXnPo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to

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 via 
a standard @Inject annotation, I'm not sure if this will have ramifications 
when I install it in Karaf.  If this works for both testing and deployment 
I'm cool with it.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 
from the bundle.  This more like what I'd do in blueprint and if I have it 
right the Pax CDI is using the same proxy mechanism as blueprint.

@OsgiServiceProvider(classes = {DataStore.class})

On Saturday, September 3, 2016 at 10:50:03 AM UTC-5, Brad Johnson wrote:
>
> I've been using the 2.17 update of Camel that more closely integrates CDI 
> 1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to 
> using it in the years ahead.  I've used blueprint for quite awhile and 
> while it works well enough the CDI simply makes development much easier and 
> testing is a snap.
>
> One problem I've run into is with the CDI testing framework.  Within 
> bundle tests or even bundles listed as dependencies work just fine.  But 
> when I try to use the @OsgiServiceProvider and @OsgiService I run into some 
> problems.  It may simply be that the regular CDI runner with Weld isn't 
> appropriate for testing service export and import.
>
> From what I can tell I'm either missing a library dependency or the CDI 
> test even within bundle will not respect the pick up or use the annotations.
>
> The @Inject in this unit test shows a squiggly yellow underline indicating 
> it can't find anything to inject.
>
> @RunWith(CamelCdiRunner.class)
> public class DevelopmentDataStoreTest {
>
> @Inject
> @OsgiService
> private DataStore datastore;
>
> In the same bundle I have am Impl of the DataStore interface that looks 
> like this:
>
> @Singleton
> @OsgiServiceProvider
> public class DevelopmentDataStoreImpl implements DataStore {
>
> I've tried a number of different permutations such as adding a 
> dynamic=true to the OsgiService annotation.
>
> The stack trace on the test seems to indicate that it understand what it 
> is I want to do but I don't have something right about it (italics are 
> mine).
>
> ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers 
> @OsgiService
>   at injection point [BackedAnnotatedField] @Inject @OsgiService private 
> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
>   at 
> org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore(DevelopmentDataStoreTest.java:0)
> WELD-001475: *The following beans match by type, but none have matching 
> qualifiers:*
> *  - Managed Bean [class 
> org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with 
> qualifiers [@OsgiServiceProvider @Any]*
>
> Italics are mine. So something is off about my annotations. Should the 
> OsgiServiceProvider be scoped differently?  For in bundle testing like this 
> I could use @Named("dataStore") and inject it that way.
>
>
> My imports look like the following:
> 
> javax.enterprise
> cdi-api
> ${cdi.version}
> 
> 
> org.ops4j.pax.cdi
> pax-cdi-api
> 1.0.0.RC1
> 
> 
> org.apache.camel
> camel-cdi
> ${camel.version}
> 2.17.3
> 
>
> 
> 
> org.apache.camel
> camel-test-cdi
> ${camel.version}
> test
> 
>
> Any help is appreciated.
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pax CDI and Camel...testing...

2016-09-03 Thread Brad Johnson 
I've been using the 2.17 update of Camel that more closely integrates CDI 
1.2 and specifically Pax CDI.  I'm quite impressed with and look forward to 
using it in the years ahead.  I've used blueprint for quite awhile and 
while it works well enough the CDI simply makes development much easier and 
testing is a snap.

One problem I've run into is with the CDI testing framework.  Within bundle 
tests or even bundles listed as dependencies work just fine.  But when I 
try to use the @OsgiServiceProvider and @OsgiService I run into some 
problems.  It may simply be that the regular CDI runner with Weld isn't 
appropriate for testing service export and import.

>From what I can tell I'm either missing a library dependency or the CDI 
test even within bundle will not respect the pick up or use the annotations.

The @Inject in this unit test shows a squiggly yellow underline indicating 
it can't find anything to inject.

@RunWith(CamelCdiRunner.class)
public class DevelopmentDataStoreTest {

@Inject
@OsgiService
private DataStore datastore;

In the same bundle I have am Impl of the DataStore interface that looks 
like this:

@Singleton
@OsgiServiceProvider
public class DevelopmentDataStoreImpl implements DataStore {

I've tried a number of different permutations such as adding a dynamic=true 
to the OsgiService annotation.

The stack trace on the test seems to indicate that it understand what it is 
I want to do but I don't have something right about it (italics are mine).

ELD-001408: Unsatisfied dependencies for type DataStore with qualifiers 
@OsgiService
  at injection point [BackedAnnotatedField] @Inject @OsgiService private 
org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore
  at 
org.enjekt.panda.developmentdatstore.DevelopmentDataStoreTest.datastore(DevelopmentDataStoreTest.java:0)
WELD-001475: *The following beans match by type, but none have matching 
qualifiers:*
*  - Managed Bean [class 
org.enjekt.panda.developmentdatastore.DevelopmentDataStoreImpl] with 
qualifiers [@OsgiServiceProvider @Any]*

Italics are mine. So something is off about my annotations. Should the 
OsgiServiceProvider be scoped differently?  For in bundle testing like this 
I could use @Named("dataStore") and inject it that way.


My imports look like the following:

javax.enterprise
cdi-api
${cdi.version}


org.ops4j.pax.cdi
pax-cdi-api
1.0.0.RC1


org.apache.camel
camel-cdi
${camel.version}
2.17.3




org.apache.camel
camel-test-cdi
${camel.version}
test


Any help is appreciated.

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.