users@jersey.java.net

Re: [Jersey] Re: deployment issues with latest glassfish build

From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
Date: Wed, 13 Oct 2010 13:41:22 +0200

On Sep 24, 2010, at 3:20 PM, John Lister wrote:

> Is it worth me filing a bug with weld on this or posting on their
> mailing list?
>

GF and Weld bugs have already been filed:

   https://glassfish.dev.java.net/issues/show_bug.cgi?id=13131


I have recently committed an alternative workaround using JNDI rather
than thread locals that potentially may stop the NPEs. Waiting for a
new build to be pushed to the java.net repo, once ready i will send an
email.

Paul.

> Thanks
>
> John
>
> On 19:59, Paul Sandoz wrote:
>>
>> On Sep 21, 2010, at 5:48 AM, John Lister wrote:
>>
>>> Hi Paul, to follow up, this seems to be a CDI/Weld issue. If I
>>> don't enable cdi then it all works fine, in addition I've verified
>>> that the new CDI
>>> changes seem to be responsible (first commited in version 3867).
>>>
>>
>> Thanks for verifying.
>>
>>
>>> A quick debug shows that the problem seems to be that the
>>> threadLocal initializedExtension is set in an "admin" http thread
>>> during deployment in initialize as part of the
>>> beforeBeanDiscovery event, whereas when jersey is called, the
>>> CDIComponentProviderFactory tries to retrieve it from a "normal"
>>> http thread. This hasn't been initialised and as such this results
>>> in null being returned from
>>> CDIExtension.getInitializedExtension(). This subsequently causes a
>>> NullPointerException when the CDIComponentProviderFactory tries to
>>> set the WebApplication using a null reference.
>>>
>>
>> OK, as we suspected deployment is occurring on a different thread
>> to the servlet initialization.
>>
>> Hmm... currently not sure how to work around this and we may need
>> to wait until Weld is fixed.
>>
>> Paul.
>>
>>
>>> Unfortunately my knowledge ends, I can see that the deployment
>>> happens in the admin threads but I'm can't figure out where the
>>> CDIExtension should be initialised..
>>>
>>> Thanks
>>>
>>> John
>>>
>>>>
>>>> On 10/09/2010 09:29, Paul Sandoz wrote:
>>>>> What version of GlassFish are you using?
>>>>
>>>> either 3.0.1-22 or 3.1.0-18 result in the issue
>>>>
>>>>> Can you provide more details on your application, preferably
>>>>> attaching a
>>>>> reproducible test case to the bug?
>>>>
>>>> Attached to the issue. It is simply a single resource class with
>>>> 1 method.
>>>> When you call the method the given exception is raised.
>>>>
>>>>> There are some fundamental errors going on here which makes me
>>>>> think there
>>>>> is a conflict between the version of Jersey deployed in the war
>>>>> and the version of Jersey distributed with GlassFish.
>>>>
>>>> They should be the same as I build the war using the jersey jars
>>>> from the
>>>> glassfish modules directory, but I could be wrong...
>>>> The version of jersey is listed as 1.4-0.4 (not what is below)
>>>> and dated
>>>> 31 Aug 2010. I was using a slightly older version from a few
>>>> weeks ago
>>>> with no issues.
>>>>
>>>> Thanks
>>>>
>>>> John
>>>>
>>>> >>On 10/09/2010 00:14, John Lister wrote:
>>>> >>Hi, using the latest dev release (1.4.04 31/08/2010) in
>>>> glassfish of
>>>> jersey I get 2 issues around deployment.
>>>>
>>>> >>Firstly when I deploy, all seems to go well except I get a
>>>> number of
>>>> warnings of the form
>>>> >>WARNING: WEB9052: Unable to load class getAbout, reason:
>>>> java.lang.ClassNotFoundException: getAbout
>>>> >>(where getAbout is a resource method) for each method within my
>>>> resources. Secondly when I try and run my application, I get a
>>>> sequence of
>>>> Null Pointer errors listed below. This seems to be caused by an
>>>> error
>>>> initialising a CDIComponentProviderFactory, calling
>>>> getInitializedExtension returns null (as no extension is assigned
>>>> to the
>>>> threadlocal variable) which causes a NullPointerException when it
>>>> tries to
>>>> assign the application. Then in the ContainerRequest constructor
>>>> another
>>>> NullPointerException results when trying to enable the tracing
>>>> because the
>>>> application hasn't been assigned.
>>>>
>>>> >>This looks to be caused by the work around for the weld
>>>> proxying bug
>>>> as previously getInitialisedExtensions wasn't called.
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>