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.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:
> <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 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.
