On Apr 22, 2010, at 4:01 PM, Morten wrote:
> Hi Poul,
>
> Many thanks for your quick answer. See my comments inline below:
>
>> 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?
>
> I do not think this is the problem I have run into. I did finally
> found out very late last night that the reason resources was not
> getting injected was that I only put the annotation
> "javax.inject.Singleton" on my controller base class and not the
> controllers themselves. Apparently, it is not inherited so after I
> moved the annotation from base class to all the controller
> subclasses it worked.
>
Right.
> However, I still get the same exception from Jersey in the and I am
> not yet sure yet why it happens and what impact it has?
>
See more details below.
> The project in question is quite large but I will try to see if I
> can reproduce it in a small test case for you. I will get back to
> you on that.
OK, thanks.
>
>>> 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
>
> Thanks. I will look in the sources also.
>
> BTW: Is there a way to update glassfish 3.0 to use the latest jersey
> jar ?
The best way is to use the GF update center. 1.1.5 is there but not
1.1.5.1, which is OK since 1.1.5.1 contains fixes just for WebLogic.
>
>> 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.
>
> Yes, the problem is that I do not have any reference to another
> controller in my code, so I have no idea where this ambiguous set is
> from... I do suspect its inside the CDI-Jersey integration though ?
>
Jersey is actually not doing much.
It listens to process injection target events on deployment. Then
iterates through those events:
for (final ProcessInjectionTarget pit :
e.getProcessInjectionTargets()) {
final Class<?> c = pit.getAnnotatedType().getJavaClass();
final Bean<?> b = getBean(c);
if (b == null)
continue;
...
private Bean<?> getBean(Class<?> c) {
final Set<Bean<?>> bs = bm.getBeans(c);
if (bs.isEmpty()) {
return null;
}
try {
return bm.resolve(bs);
} catch(AmbiguousResolutionException ex) {
LOGGER.log(Level.SEVERE, null, ex);
return null;
}
}
So in this case it is obtaining the class of the annotated type
associated with a process injection target (PIT) event. Then it
attempts to obtain the CDI meta-data about the class, the resolved
Bean, so it can know the scope and correctly inject JAX-RS/Jersey
artifacts.
In your application, for a certain class, CDI cannot resolve a Bean
for the class. Jersey will continue attempting to process the other
PIT events. I am not sure that logging an exception is correct or not,
and i am not sure Jersey cannot really adapt a PIT that is ambiguous
in terms of the Bean to Class mapping. I am not sure how one can
configure the app to produce such a condition. I dunno how your CDI
classes:
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
are annotated to produce such a condition.
>> Again seeing more code, preferably a test case would help
>> me work out better what is going on.
>
> It is non-trivial to produce but I will see what I can do (unless
> you have a clear idea where in CDI-jersey the ambiguous set is used ?)
>
No clear idea, i would need to look at the application code.
Paul.