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 Fri, 14 Apr 2017 08:46:04 GMT
Hi

I will try to reproduce it by calling the jax rs service early (did try
before but failed but will give it a go again). It will either be me or
Lars Östberg (we are in the same project) that opens the PMR.

Also note that when it does not work it does not work for any of the
requests until restart. And if it does work it does not seems to fail at
all.

Regards
Lars-Fredrik Smedberg

Den 14 apr. 2017 05:09 skrev "Andy McCright" <j.andrew.mccright@gmail.com>:

> Hi Lars-Fredrik,
>
> If the issue is related to background servlet initialization, then you may
> be able to reproduce the problem by invoking the services as early as
> possible - maybe write a script that starts the server (in the background)
> and then invokes the service repeatedly using a command line tool like
> curl.
>
> As for opening a PMR, you could certainly open one with the information you
> have provided so far, but the more details you can provide, the better.
>
> My team and I will be moving to a new building tomorrow and Monday, so I
> may be slow to respond.  I would like to try to reproduce this issue with a
> smaller test case.
>
> Thanks,
>
> Andy
>
> On Thu, Apr 13, 2017 at 6:25 AM Lars-Fredrik Smedberg <itsmeden@gmail.com>
> wrote:
>
> > 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