Hi! Please see the answers inline below.
Thanks for the help Regards LF On Wed, Apr 12, 2017 at 3:41 AM, Andy McCright <[email protected]> wrote: > 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. > To be honest we are not 100% sure of when we saw it the first time. It might have occured before WLP 17.0.0.1 but the errors we see now are all on WLP 17.0.0.1. > > It sounds like the injection is working correctly - it is injecting a > Yes the injection seems to work, the injected proxy is not null and the NPE is thrown from inside the proxy when there are no ResourceInfo available on TLS (if I understood it correct). > 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 > We have always been using CDI together with JAX-RS 2.0, here is the feature set we use: <!-- Common features --> <feature>cdi-1.2</feature> <feature>jaxrs-2.0</feature> <feature>ejbLite-3.2</feature> <feature>jaxb-2.2</feature> <feature>wmqJmsClient-2.0</feature> <feature>beanValidation-1.1</feature> <feature>jsonp-1.0</feature> <!-- Resource features --> <feature>apiDiscovery-1.0</feature> <feature>appSecurity-2.0</feature> <feature>collectiveMember-1.0</feature> <feature>clusterMember-1.0</feature> <feature>jdbc-4.1</feature> <feature>jndi-1.0</feature> <feature>ldapRegistry-3.0</feature> <feature>localConnector-1.0</feature> <feature>monitor-1.0</feature> <feature>restConnector-1.0</feature> <feature>ssl-1.0</feature> <feature>zosTransaction-1.0</feature> <feature>zosWlm-1.0</feature> <feature>zosRequestLogging-1.0</feature> > 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. > > We don't have a deterministic way of reproducing this error. It happens occasionally (about 15-20% of the times but not on all installation as it seems). > If all else fails, I would suggest opening a PMR with IBM Support. > > Would you suggest open a PMR that just describes our problem even though we can not produce code that each time will reproduce the error? > 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. > > > -- 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.
