It proved CXFNonSpringJaxrsServlet had imported a wrong ClassUtils; just rerun today the TCK with 2.2.4-SNAPSHOT and CXFNonSpringJaxrsServlet was loading application classes just fine from a shared folder
also added "jaxrs.schemaLocations" init parameter too Sergey Sergey, On Thu June 25 2009 11:33:47 am Sergey Beryozkin wrote: > I think ssl is not the issue here. I've used CXFNonSpringJaxrsServlet when > working on TCK and to bypass this issue I had to copy > org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet (only) to a given > web > app classes folder, I presuming CXF libs are in shared tomcat folder. > > May be we can do something similar to what Spring does by somehow making > the child web app loader visible to the parent one loading CXF classes. > For > now please extract this class from CXF libs... You really shouldn't need to do that. The Thread.contextClassLoader SHOULD be the classloader of the application/war. Anything we do that dynamically loads classes or anything should be using the contextClassLoader. That should make it so the CXFNonSpringJaxrsServlet doesn't need to be munged in that way. Dan -- View this message in context: http://www.nabble.com/xsd-Validation-and-CXFNonSpringJaxrsServlet-and-ssl-tp24202869p25722066.html Sent from the cxf-user mailing list archive at Nabble.com.
