dev@jersey.java.net

Re: [Jersey] Difficulties getting the new CDI impl to work with the sample

From: Roberto Chinnici <roberto.chinnici_at_oracle.com>
Date: Fri, 13 Aug 2010 14:53:19 -0700

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.

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.