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/
> 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 ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
