Hi,
On Apr 22, 2010, at 2:08 AM, Morten wrote:
> I have trouble getting jersey to work reliable under glassfish 3. It
> works for very simple cases but in other cases the CDI-weld
> integration is not working (javax.inject.Inject sometimes ignored on
> javax.inject.Singleton annotated controllers). Looking in the log,
> jersey's undocumented JCDIComponentProviderFactory seems to produce
> quite some strange exceptions f.x. this one about an ambiguous
> dependency between my jersey controllers (very strange since I am
> not aware of any links to a controller unless jersey does some magic
> and fails).
>
You may be running into:
https://jersey.dev.java.net/issues/show_bug.cgi?id=423
which was fixed in 1.1.5. GF v3 ships with 1.1.4.1.
Hard to say why without looking at code, can you send me a
reproducible test case?
> P.S. I tried to look in the source for JCDIComponentProviderFactory
> in the glassfish's jersey osgi bundle but could not find the source
> unlike for other jersey modules??
>
Yes, the sources are not pushed for that (it is an error). The Java
source is the same as the jersey-bundle:
http://download.java.net/maven/2/com/sun/jersey/jersey-bundle/1.1.5.1/jersey-bundle-1.1.5.1-sources.jar
> Exception below:
>
> #|2010-04-22T01:51:17.141+0200|SEVERE|glassfish3.0|
> com.sun.jersey.server.impl.jcdi.JCDIComponentProviderFactory|
> _ThreadID=24;_ThreadName=Thread-1;|The log myappmessage is null.
> org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318
> Cannot resolve an ambiguous dependency between [org.jboss.weld.bean-/
> Users/Shared/Java/glassfishv3/glassfish/domains/domain1/eclipseApps/
> product-ws/-ManagedBean-class
> com.myapp.ws.controller.ServiceController, org.jboss.weld.bean-/
> Users/Shared/Java/glassfishv3/glassfish/domains/domain1/eclipseApps/
> product-ws/-ManagedBean-class com.myapp.ws.controller.MyController,
> org.jboss.weld.bean-/Users/Shared/Java/glassfishv3/glassfish/domains/
> domain1/eclipseApps/product-ws/-ManagedBean-class
> com.myapp.ws.controller.ControllerBase, org.jboss.weld.bean-/Users/
> Shared/Java/glassfishv3/glassfish/domains/domain1/eclipseApps/
> product-ws/-ManagedBean-class com.myapp.ws.controller.GuiController,
> org.jboss.weld.bean-/Users/Shared/Java/glassfishv3/glassfish/domains/
> domain1/eclipseApps/product-ws/-ManagedBean-class
> com.myapp.ws.controller.AdminController]
> at
> org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:
> 1160)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .jcdi
> .JCDIComponentProviderFactory
> .getBean(JCDIComponentProviderFactory.java:244)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .jcdi
> .JCDIComponentProviderFactory.init(JCDIComponentProviderFactory.java:
> 103)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .application.WebApplicationImpl.initiate(WebApplicationImpl.java:654)
>
> Any ideas ?
>
It looks like there is more than one reference available for the an
"annotated type" of an injection target:
com.myapp.ws.controller.ServiceController,
com.myapp.ws.controller.MyController,
com.myapp.ws.controller.ControllerBase,
com.myapp.ws.controller.GuiController,
com.myapp.ws.controller.AdminController
and the Set<Bean<?>> of the above cannot be resolved to one Bean<?>
instance and thus Jersey does not know how to adapt the injection
target for it's own injection. So Jersey prints logs an error, perhaps
it should not and instead should ignore.
Again seeing more code, preferably a test case would help me work out
better what is going on.
Paul.