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.
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.