cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: NPE when calling methods on ResourceInfo using WLP 17.0.0.1
Date Thu, 13 Apr 2017 11:24:58 GMT
Hi again

You say that this might be a timing/threading/sync problem.... do you have
any suggestion on how I more easy can reproduce the problem to be able to
suply logs...

Regarss
LF


Den 13 apr. 2017 11:44 skrev "Lars-Fredrik Smedberg" <itsmeden@gmail.com>:

> Hi!
>
> Please see the answers inline below.
>
> Thanks for the help
>
> Regards
> LF
>
>
> On Wed, Apr 12, 2017 at 3:41 AM, Andy McCright <
> j.andrew.mccright@gmail.com> 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.*=a
>> ll"
>> 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 <
>> itsmeden@gmail.com>
>> 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message