Hi, Have you tried this same application on previous versions of Liberty and had different results? WLP 17.0.0.1 introduced a behavior change with the background initialization of servlets that may be contributing to this condition. It you did not see this problem with 16.0.0.4 or previous, then that might be the issue.
It sounds like the injection is working correctly - it is injecting a ThreadLocal proxy. But it sounds like that ThreadLocalInvocationHandler has not been configured correctly to point at the underlying ResourceInfo object. The way this works so that multiple threads accessing potentially different resources from the same field object is by using the ThreadLocalInvocationHandler - each thread will be accessing a proxy that invokes methods on the object that is specific to that thread. So it is possible that there is some timing issue - where the thread's ResourceInfo implementation object has not be specified until after it is invoked. You mentioned that you have other Liberty features installed. What are they? If you are using a CDI feature, would it be possible to try this scenario without it (or if you don't have CDI enabled, could you enable it)? When the jaxrs-2.0 feature is enabled with the cdi-1.2 feature, then the CDI implementation handles the injection. So changing the injection mechanism may yield different results. If none of this helps, it would be good to get a trace of both the working and failing scenarios - the logging configuration that I would suggest is: <logging traceSpecification="com.ibm.ws.jaxrs*=all:org.apache.cxf.*=all" maxFileSize="0" /> By setting the maxFileSize to 0, it keeps all of the data in one trace.log file instead of using rolling logs. If all else fails, I would suggest opening a PMR with IBM Support. Hope this helps, Andy On Tue, Apr 11, 2017 at 4:15 PM, Lars-Fredrik Smedberg <[email protected]> wrote: > Hi! > > We are using running WLP 17.0.0.2 using the JAX-RS 2.0 feature (among > others) to be able to inject (using @Context) ResourceInfo. > > We are calling getResourceClass() and getResourceMethod() on the injected > ResourceInfo to get the matching resource/method (for statistical logging > and more). > > Sometimes we get a NPE when calling getResourceClass(). The NPE happens > internally in the proxy being injected, see stacktrace below. > We inject the ResourceInfo in a JAX-RS request filer (@Provider, > @Priority...). > > It is hard to reproduce consistently since it does not happen all the time, > I try to describe the behavior below: > > - It only occurs (sometimes) after application server start and when it > occurs it occurs for ALL requests (that is NO request using the request > filter can successfully call getResourceClass() on the injected > ResourceInfo). > - When it occurs it occurs for ALL subsequent calls and does not dissapere > until the application server has been restarted. > - If it works after application server start it seems to work for ALL > subsequent requests. > - ResourceInfoUtils:33 (as seen in the stacktrace below) calls > getResourceClass() on the injected ResourceInfo. > > Has anyone seen this or similar problems? CXF or IBM WLP integration > problem? Appreciate any help on this. > > Regards > Lars-Fredrik Smedberg > > -------------------------------------------- > > Stacktrace: > > javax.ws.rs.container.ResourceInfo context class has not been injected. > Check if ContextProvider supporting this class is registered > java.lang.NullPointerException: javax.ws.rs.container.ResourceInfo context > class has not been injected. Check if ContextProvider supporting this class > is registered > at > org.apache.cxf.jaxrs.impl.tl.ThreadLocalInvocationHandler.invoke( > ThreadLocalInvocationHandler.java:42) > at com.sun.proxy.ÅProxy210.getResourceClass(Unknown Source) > at > shb.rast.ws.rs.filter.ResourceInfoUtils.getTemplateUri( > ResourceInfoUtils.java:33) > at > shb.rast.ws.rs.filter.AvailabilityRequestFilter.getAction( > AvailabilityRequestFilter.java:160) > at > shb.rast.ws.rs.filter.AvailabilityRequestFilter.filter( > AvailabilityRequestFilter.java:92) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.runContainerRequestFilters( > JAXRSUtils.java:1686) > at > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest( > JAXRSInInterceptor.java:244) > at > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage( > JAXRSInInterceptor.java:85) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept( > PhaseInterceptorChain.java:308) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage( > ChainInitiationObserver.java:124) > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke( > AbstractHTTPDestination.java:265) > at > com.ibm.ws.jaxrs20.endpoint.AbstractJaxRsWebEndpoint.invoke( > AbstractJaxRsWebEndpoint.java:134) > at > com.ibm.websphere.jaxrs.server.IBMRestServlet. > handleRequest(IBMRestServlet.java:149) > at > com.ibm.websphere.jaxrs.server.IBMRestServlet.doGet( > IBMRestServlet.java:115) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at > com.ibm.websphere.jaxrs.server.IBMRestServlet.service( > IBMRestServlet.java:99) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper. > service(ServletWrapper.java:1290) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper. > handleRequest(ServletWrapper.java:778) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper. > handleRequest(ServletWrapper.java:475) > at > com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget( > WebAppFilterChain.java:152) > at > com.ibm.ws.webcontainer.filter.WebAppFilterChain. > doFilter(WebAppFilterChain.java:94) > > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments. >
