On Aug 13, 2010, at 11:53 PM, Roberto Chinnici wrote:
> Paul Sandoz wrote:
>> Hi Roberto,
>>
>> I am getting some odd errors when deploying the CDI sample (i
>> needed to modify it to add a beans.xml) with the latest version of
>> Jersey copied into GlassFish promoted build 15.
>>
>> When i deploy i am getting an NPE in the CDIExtension class at:
>>
>> void lateInitialize() {
>> // NPE here because toBeInitializedLater is null
>> for (InitializedLater object : toBeInitializedLater) {
>> object.later();
>> }
>> }
>>
>> I verified that the CDIExtension appears to be behaving as required
>> via the log messages i.e. the before bean discovery event occurs:
>>
>> void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event) {
>> initialize();
>>
>> // turn JAX-RS injection annotations into CDI qualifiers
>> for (Class<? extends Annotation> qualifier :
>> knownParameterQualifiers) {
>> event.addQualifier(qualifier);
>> }
>> }
>>
>> I also verified that the value of the CDIExtension.toString is the
>> same for the instance that is created and the instance that is
>> looked up using the BeanManager:
>>
>> public void onWebApplicationReady() {
>> CDIExtension extension = Utils.getInstance(beanManager,
>> CDIExtension.class);
>>
>> extension.lateInitialize();
>> }
>>
>>
>> However the concrete class is of CDIExtension of the reference that
>> is looked up via BeanManager is:
>>
>> class com.sun.jersey.server.impl.cdi.CDIExtension_$$_WeldProxy
>>
>> I suspect that weld proxying is not working correctly and the
>> method calls on the proxy reference are not being correctly
>> delegated to the proxied instance.
>
> That's what I see too.
>
> FWIW, the proxy is created early on, before the BeforeBeanDiscovery
> event is fired.
>
> The bean registered with the BeanManager for the CDIExtension is
> ApplicationScoped, as it should according to the spec.
>
> So it seems the only issue is that the proxy is not proxying... :-(
>
> As a test, I tried passing the initialized CDIExtension to the
> CDIComponentProviderFactory via a ThreadLocal, instead of going
> through the BeanManager, and everything works correctly.
>
! i guess that could server as a temporary workaround.
> Another data point. When I deploy Jersey 1.4-SNAPSHOT (jersey-
> server.jar and everything else) inside a webapp on GF 3.0.1, I see
> that a proxy gets created, but the bean handed out by the
> BeanManager is not proxied.
>
> Also on GF 3.0.1 the proxy class is called
> com.sun.jersey.server.impl.cdi.CDIExtension_$$_javassist_18, so it's
> entirely possible that the Weld proxy code was changed recently.
>
Yes, that was confirmed by Siva on the GF dev list.
Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>