javaee
Ambiguous dependencies injection when using the new CDI2
Hi Jersey team,
using the new CDI2 bridge for jersey, I have this error :
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject org.glassfish.jersey.tests.integration.jersey2704.TestResource.request
at org.glassfish.jersey.tests.integration.jersey2704.TestResource.request(TestResource.java:0)
Possible dependencies:
- org.glassfish.jersey.inject.cdi.se.bean.SupplierBeanBridge@56820446,
- org.glassfish.jersey.inject.cdi.se.bean.SupplierBeanBridge@c14bbab
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:383)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:287)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:140)
at org.jboss.weld.bootstrap.Validator.validateCustomBean(Validator.java:195)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:520)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:63)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:61)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Here a test case for it : https://github.com/hypnoce/jersey/commit/7e8a4c7b88c3e57946541335877b545791422905
The execution flow is the following :
- In WebComponent.java#L330 a WebComponentBinder is registered into the resource config.
- This binder is then passed to the ApplicationHandler and is then registered in the injectionmanager of the handler
- At one point in time, the config binders (and therefore the one that has been registered) are registered in the injection manager.
- At the end, CdiSeInjectionManager#register is called twice with the same exact binder.
I have the same problem. Is there any workaround that I can do on the application side before the bug is fixed ? thanks
Same problem here. Any workarounds for that? I need to access the HttpServletRequest or the Session inside of a ContainerRequestFilter.
Even programmatic lookup via CDI.current().select() was not successfully. I could iterate over the 2 found Instances for HttpServletRequest, unfortunately both were implementations of ResponseFacade. WTF?!?
My workaround was a migration to RestEasy. #SAD
In general, I believe jersey is a dying project. No bug fix, no impovements, poor commiter community. Resteasy (wildfly-swarm flavor) is the way to go for microservices with java standards.
@hypnoce I think the community is waiting on Oracle for the Jersey to be handed over to the Eclipse Foundation, at that point I expect work on it to resume in earnest. See also #3710.
