cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Validation, CXF, OSGi, TCCL, once more
Date Mon, 21 Dec 2015 23:57:35 GMT
I single-stepped through the service creation, and I didn't spot any
capturing of a class loader by the bus initialization. I'm probably
being dense.

On Mon, Dec 21, 2015 at 6:47 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> Definitely the HTTP transport.
>
> ResourceDelegatingBundleClassLoader{bundle=org.apache.cxf.cxf-rt-transports-http
> [110],parent=BundleClassLoader{bundle=org.ops4j.pax.web.pax-web-jetty
> [221],parent=null}}
>
> Here's the whole backtrace.
>
> "qtp1894429215-109@4540" prio=5 tid=0x6d nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at com.basistech.ws.common.api.options.OptionsValidator.validate(OptionsValidator.java:36)
>  at com.basistech.ws.common.api.options.ProcessingOptions$Builder.setOptions(ProcessingOptions.java:124)
>  at com.basistech.ws.frontend.service.AbstractRaasRsService.getProcessingOptions(AbstractRaasRsService.java:756)
>  at com.basistech.ws.frontend.service.AbstractRaasRsService.processRequest(AbstractRaasRsService.java:582)
>  at com.basistech.ws.frontend.service.AbstractRaasRsService.processHelper(AbstractRaasRsService.java:210)
>  at com.basistech.ws.frontend.service.RaasRsEntityService.runEntityExtraction(RaasRsEntityService.java:108)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:497)
>  at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180)
>  at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
>  at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:200)
>  at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:99)
>  at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
>  at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:96)
>  at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  - locked <0x254e> (a org.apache.cxf.phase.PhaseInterceptorChain)
>  at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
>  at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>  at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
>  at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
>  at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:212)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>  at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
>  at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
>  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
>  at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
>  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>  at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>  at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>  at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>  at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>  at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>  at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>  at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
>  at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>  at org.eclipse.jetty.server.Server.handle(Server.java:497)
>  at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>  at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>  at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>  at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>  at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>  at java.lang.Thread.run(Thread.java:745)
>
> On Mon, Dec 21, 2015 at 6:40 PM, Benson Margulies <bimargulies@gmail.com> wrote:
>> On Mon, Dec 21, 2015 at 3:54 PM, Daniel Kulp <dkulp@apache.org> wrote:
>>> Benson,
>>>
>>> Can you walk back through the stack a bit…  I BELIEVE that pax-web should be
invoking one of our servlets which should then be getting into the ServletController.  In
the invoke method in there, it grabs the Bus from the destination and sets the TCCL to the
ClassLoader it has recorded.  That SHOULD be the class loader for the bundle where the service
is started.   Can you check if that’s the pathway it going through?   If so, then the question
is why is the class loader NOT be set appropriately.   What bus is being used?   Where is
that Bus created?   Etc….
>>
>> Dan,
>>
>> Here's what I know, and then I'll need to do some research.
>>
>> Situation:
>>
>> Karaf 4.0.2, CXF 3.1.4. JAX-RS services registered with the service
>> factory in a DS @Activate method. Code that registers the service is
>> below at  [1], so if there's an API to pass in a ClassLoader, I was
>> ignorant and failed to call it. I have whatever bus sprung itself into
>> existence in the code below. Perhaps I should make a bus explicitly
>> and shove a class loader into it?
>>
>> Observation: when a resource method is called, TCCL is not me, leading
>> to all the HV trouble. I think it might be the HTTP transport bundle,
>> but Karaf logging may have mislead me.
>>
>> I will go now and set a breakpoint and report back with a more
>> reliable indication.
>>
>>
>> [1]:
>>
>> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
>> sf.setProvider(new JacksonJaxbJsonProvider(JsonUtils.getObjectMapper(),
>>         JacksonJaxbJsonProvider.DEFAULT_ANNOTATIONS));
>> sf.setProvider(new JsonExceptionMapper());
>> sf.setProvider(new WebApplicationExceptionMapper());
>> sf.setProvider(new GenericExceptionMapper());
>> sf.setServiceBeans(Collections.singletonList(this));
>>
>> String url = urlPrefix + resourcePath;
>> LOG.info(String.format("%s at %s", getClass().getName(), url));
>> sf.setAddress(url);
>> server = sf.create();
>>
>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>> On Dec 21, 2015, at 3:35 PM, Benson Margulies <bimargulies@gmail.com>
wrote:
>>>>
>>>> Working with Gunnar, I've finally gotten a complete picture of the
>>>> situation, and a somewhat general question has come up.
>>>>
>>>> When pax-web calls CXF which in turn calls a JAX-RS resource class,
>>>> the TCCL is the CXF http transport bundle class loader. Is there some
>>>> reason not to set it to a class loader associated with the resource
>>>> class?
>>>>
>>>> The trouble with HibernateValidation is this: way down in HV, there's
>>>> a call to ExpressionFactory.newInstance() from javax.el. That's an
>>>> old-fashioned SPI that does not have an overload that takes a
>>>> ClassLoader. So, even though HV has a class loader option in its
>>>> configuration meant to ensure the findability of resources, it does
>>>> not avail. (Unless HV set the TCCL, which its authors are not happy
>>>> about.) I'm working with them on an API that will allow the user of HV
>>>> to make their own ExpressionFactory with the TCCL set however they
>>>> like. However, it did occur to me that a different TCCL in CXF
>>>> invoking JAX-RS would have avoided all this.
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>

Mime
View raw message