cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Validation, CXF, OSGi, TCCL, once more
Date Mon, 21 Dec 2015 23:47:11 GMT
Definitely the HTTP transport.


Here's the whole backtrace.

"qtp1894429215-109@4540" prio=5 tid=0x6d nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at sun.reflect.NativeMethodAccessorImpl.invoke0(
 at sun.reflect.NativeMethodAccessorImpl.invoke(
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(
 at java.lang.reflect.Method.invoke(
 at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(
 at org.apache.cxf.service.invoker.AbstractInvoker.invoke(
 at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(
 at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(
 at org.apache.cxf.interceptor.ServiceInvokerInterceptor$
 at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(
 at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
 - locked <0x254e> (a org.apache.cxf.phase.PhaseInterceptorChain)
 at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
 at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
 at org.apache.cxf.transport.servlet.ServletController.invokeDestination(
 at org.apache.cxf.transport.servlet.ServletController.invoke(
 at org.apache.cxf.transport.servlet.ServletController.invoke(
 at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(
 at javax.servlet.http.HttpServlet.service(
 at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(
 at org.eclipse.jetty.servlet.ServletHolder.handle(
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(
 at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(
 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 at org.eclipse.jetty.server.session.SessionHandler.doHandle(
 at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
 at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(
 at org.eclipse.jetty.servlet.ServletHandler.doScope(
 at org.eclipse.jetty.server.session.SessionHandler.doScope(
 at org.eclipse.jetty.server.handler.ContextHandler.doScope(
 at org.eclipse.jetty.server.handler.ScopedHandler.handle(
 at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(
 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
 at org.eclipse.jetty.server.Server.handle(
 at org.eclipse.jetty.server.HttpChannel.handle(
 at org.eclipse.jetty.server.HttpConnection.onFillable(
 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
 at org.eclipse.jetty.util.thread.QueuedThreadPool$

On Mon, Dec 21, 2015 at 6:40 PM, Benson Margulies <> wrote:
> On Mon, Dec 21, 2015 at 3:54 PM, Daniel Kulp <> 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;
>"%s at %s", getClass().getName(), url));
> sf.setAddress(url);
> server = sf.create();
>> Dan
>>> On Dec 21, 2015, at 3:35 PM, Benson Margulies <> 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
>> -
>> Talend Community Coder -

View raw message