dev@glassfish.java.net

Re: Issues with Jersey's new CDI integration and weld proxying on GF 3.1 b16-08_11_2010

From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
Date: Mon, 16 Aug 2010 12:50:08 +0200

Hi Siva,

What the stack trace, below, shows is the Jersey servlet obtaining
information from the CDIExtension it has looked up using the
BeanManager, and the NPE is the result of a field on CDIExtension
instance is null. Not sure it will make much sense to you.

Roberto verified that if a static thread local variable is used to
pass the CDExtension implementation to the Jersey servlet then things
work correctly.

I am out of ideas on how to distill this down to something
reproducible independent Jersey so i think it may be easier if you can
reproduce using Jersey and debug from that.

Follow the instructions here to install the latest Jersey bits to GF:

   https://jersey.dev.java.net/nonav/documentation/1.4-SNAPSHOT/user-guide.html
#d4e1797

Then download a maven-based sample:

   http://download.java.net/maven/2/com/sun/jersey/samples/jersey-cdi/1.4-SNAPSHOT/jersey-cdi-1.4-SNAPSHOT-gf-project.zip

unzip it and build it, and deploy the war to GF.


The extension class was proxied on 3.0.1 but Roberto informed me it
was slightly different in name:

   com.sun.jersey.server.impl.cdi.CDIExtension_$$_javassist_18

Paul.

On Aug 16, 2010, at 9:51 AM, Sivakumar Thyagarajan wrote:

> Hi Paul
>
> We had integrated an initial version of Weld 1.1 for GF 3.1 MS3. In
> Weld 1.1, there are changes being made to the way bean proxies are
> serialized and proxy classes are loaded. This NPE may be a result of
> these changes. Could you share the NPE? I can investigate further
> and we can raise a Weld issue if required.
>
> Was the Jersey Extension proxied in 3.0.1 as well? I also tried
> looking up a simple portable extension through BeanManager in a
> Servlet and did not get a proxied reference.
>


[#|2010-08-14T16:36:58.449+0200|SEVERE|glassfish3.1|
javax.enterprise.system.container.web.com.sun.enterprise.web|
_ThreadID=14;_ThreadName=Thread-1;|WebModule[/jersey-
cdi]StandardWrapper.Throwable
java.lang.NullPointerException
        at
com
.sun
.jersey.server.impl.cdi.CDIExtension.lateInitialize(CDIExtension.java:
743)
        at
com
.sun
.jersey
.server
.impl
.cdi
.CDIComponentProviderFactory
.onWebApplicationReady(CDIComponentProviderFactory.java:90)
        at
com
.sun
.jersey
.server
.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:
1175)
        at com.sun.jersey.server.impl.application.WebApplicationImpl.access
$600(WebApplicationImpl.java:160)
        at com.sun.jersey.server.impl.application.WebApplicationImpl
$12.f(WebApplicationImpl.java:697)
        at com.sun.jersey.server.impl.application.WebApplicationImpl
$12.f(WebApplicationImpl.java:694)
        at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:177)
        at
com
.sun
.jersey
.server
.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:
694)
        at
com
.sun
.jersey
.server
.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:
689)
        at
com
.sun
.jersey
.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:
435)
        at com.sun.jersey.spi.container.servlet.ServletContainer
$InternalWebComponent.initiate(ServletContainer.java:284)
        at
com
.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:
583)
        at
com
.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:
213)
        at
com
.sun
.jersey
.spi.container.servlet.ServletContainer.init(ServletContainer.java:339)
        at
com
.sun
.jersey
.spi.container.servlet.ServletContainer.init(ServletContainer.java:513)
        at javax.servlet.GenericServlet.init(GenericServlet.java:240)
        at
org
.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:
1423)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:
1225)
        at
org
.apache
.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5039)
        at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
5331)
        at com.sun.enterprise.web.WebModule.start(WebModule.java:493)
        at
org
.apache
.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:913)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:
897)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:
693)
        at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:
1921)
        at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:
1600)
        at com.sun.enterprise.web.WebApplication.start(WebApplication.java:96)
        at org.glassfish.internal.data.EngineRef.start(EngineRef.java:127)
        at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:238)
        at
org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:
256)
        at
com
.sun
.enterprise
.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:364)
        at
com
.sun
.enterprise
.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:204)
        at
org
.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:
332)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl
$1.execute(CommandRunnerImpl.java:362)
        at
com
.sun
.enterprise
.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:377)
        at
com
.sun
.enterprise
.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1077)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access
$1200(CommandRunnerImpl.java:95)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl
$ExecutionContext.execute(CommandRunnerImpl.java:1201)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl
$ExecutionContext.execute(CommandRunnerImpl.java:1190)
        at
com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:
379)
        at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:
205)
        at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:
166)
        at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:
113)
        at
com
.sun
.enterprise
.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
        at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
        at
com
.sun
.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:
220)
        at
com
.sun
.grizzly
.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:
135)
        at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
102)
        at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
88)
        at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:
76)
        at
com
.sun
.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:
53)
        at
com
.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:
57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool
$Worker.doWork(AbstractThreadPool.java:530)
        at com.sun.grizzly.util.AbstractThreadPool
$Worker.run(AbstractThreadPool.java:511)
        at java.lang.Thread.run(Thread.java:619)

> Thanks
> --Siva.
> On Friday 13 August 2010 03:07 PM, Paul Sandoz wrote:
>> Hi,
>>
>> Roberto recently re-implemented Jersey's CDI integration to better
>> support @Inject. Roberto verified that it works on GF 3.0.1.
>>
>> We are noticing what appears to be incorrect behavior with the
>> implementation of Jersey's javax.enterprise.inject.spi.Extension
>> for GF
>> 3.1b16-08_11_2010 when we install the latest Jersey artifacts built
>> from
>> source.
>>
>> This Extension implementation does a fair bit of work adapting the
>> CDI
>> model. The extension also stores some state and that state will be
>> looked up later by Jersey's servlet which obtains a reference to the
>> Extension implementation using the bean manager. However, when
>> looking
>> up the state, by making a method invocation on the reference, an NPE
>> occurs because a field on the Extension implementation in null.
>>
>> I verified that the reference is a proxy to the Extension
>> implementation:
>>
>> class com.sun.jersey.server.impl.cdi.CDIExtension_$$_WeldProxy
>>
>> it seems the only way the NPE can occur is if the proxy is not
>> working
>> correctly and the method invocation on the reference/proxy does not
>> delegate to the actual proxied implementation.
>>
>> In fact we do not understand why the Extension implementation would
>> be
>> proxied at all since there is no scope defined.
>>
>>
>> The previous implementation of Jersey's CDI integration does
>> something
>> similar but yet does not fail on an NPE.
>>
>> Also i tried to reproduce by writing a simple web-app emulating the
>> approach and proxying of the Extension implementation does not occur.
>> However, i do notice that two instances of the Extension
>> implementation
>> is constructed, implying that Weld might want to do proxying.
>>
>> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>