Open ops4j-issues opened 9 years ago
Florian Brunner commented
I'm working on this issue here: https://github.com/puce77/org.ops4j.pax.cdi/tree/PAXCDI-164-OsgiServiceProvider-Support-ParameterizedType
Florian Brunner commented
A pull request fixing this issue is available here: https://github.com/ops4j/org.ops4j.pax.cdi/pull/16
Harald Wellmann commented
I can't merge the pull request without tests.
Besides, it seems you only addressed the producer side which is easy. The consumer side is a bit harder, i.e. making sure that this works:
@Inject
@OsgiService
private SomeService<SomeType> myService;
Florian Brunner commented
I've provided the tests (including consumer side): https://github.com/ops4j/org.ops4j.pax.cdi/pull/16/files
Harald Wellmann commented
Yes, there is a test, but this is nowhere near the required coverage.
Take a look at
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#assignable_parameters
How would you deal with this:
@OsgiServiceProvider
public class MyServiceImpl<Foo> implements MyService<Foo> {...}
@OsgiServiceProvider
public class MyServiceImpl<Foo> implements MyService<Bar> {...}
@Inject
@OsgiService
private MyService ip1;
@Inject
@OsgiService
private MyService<Object> ip2;
@Inject
@OsgiService
private MyService<Foo> ip3;
@Inject
@OsgiService
private MyService<Bar> ip4;
What about parameterized parameters, e.g. MyService<Map<Foo, List<String>>>
?
Moreover, according to http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#managed_beans
If the managed bean class is a generic type, it must have scope
@Dependent
. If a managed bean with a parameterized bean class declares any scope other than@Dependent
, the container automatically detects the problem and treats it as a definition error.
Since OSGi service beans have one of the OSGi scopes @SingletonScope
, @BundleScoped
or @PrototypeScope
, parameterized OSGi service beans would be a logical contradiction.
Florian Brunner commented
This issue addresses one concrete ClassCastException. There might be a need for follow-up issues to reach full CDI conformity, but the current behavior (ClassCastException) is surely wrong and this patch solves this issue.
I have a concrete need for this: https://github.com/Drombler/drombler-fx/blob/%2337-cdi/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/FXDockableFactory.java
Applying this patch solves the issue without having to fall back to raw types and thus improves the current state of PAX-CDI.
The test and the sample prove this.
Florian Brunner commented
I've changed the title of this issue to make it more clear.
Florian Brunner created PAXCDI-164
@OsgiServiceProvider
should support services implementing parameterized interfaces:The current exception is:
Affects: 0.11.0 Fixed in: 1.1.4 Votes: 0, Watches: 2