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 <brad.john...@mediadriver.com>
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 <gno...@gmail.com> 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:
>>> <dependency>
>>> <groupId>javax.enterprise</groupId>
>>> <artifactId>cdi-api</artifactId>
>>> <version>${cdi.version}</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.ops4j.pax.cdi</groupId>
>>> <artifactId>pax-cdi-api</artifactId>
>>> <version>1.0.0.RC1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.apache.camel</groupId>
>>> <artifactId>camel-cdi</artifactId>
>>> <version>${camel.version}</version>
>>> 2.17.3
>>> </dependency>
>>>
>>> <!-- testing -->
>>> <dependency>
>>> <groupId>org.apache.camel</groupId>
>>> <artifactId>camel-test-cdi</artifactId>
>>> <version>${camel.version}</version>
>>> <scope>test</scope>
>>> </dependency>
>>>
>>> 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 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 ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
