If you are using Spring or Blueprint to create the services, the factories
would have grabbed the Bus from the blueprint/spring context which would have
had a ClassLoader specific for that bundle. You are using java code and
thus would be getting the “Default Bus” which is:
1) Not unique for that bundle/service - thus there can be some cross
“contamination”. (you can lookup services/destinations and such from other
bundles)
2) Would not have a defined class loader as the bus is “shared”.
You should be able to do something like:
Bus bus = BusFactory.createBus();
bus.setExtension(loader, ClassLoader.class);
servicefactory.setBus(bus);
to make sure it has a unique bus that has the proper class loader.
Dan
> On Dec 21, 2015, at 6:57 PM, Benson Margulies <bimargul...@gmail.com> wrote:
>
> 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 <bimargul...@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 <bimargul...@gmail.com>
>> wrote:
>>> On Mon, Dec 21, 2015 at 3:54 PM, Daniel Kulp <dk...@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 <bimargul...@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
>>>> dk...@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
