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 > On Dec 21, 2015, at 3:35 PM, Benson Margulies <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
