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.