"darran.lofthouse(a)jboss.com" wrote : I have for the JBossWS to Tomcat deployment working now. | | Looking at the scanning thread when running within Tomcat the classloader at the time is a CrossContextLoader, if we just create a classloader similar to the CrossContextLoader that includes the jars and classes of the war being deployed we should have everything we need to be able to load the classes to test for @WebService. | | We also need to include the main tomcat libs. Not sure if this loader you refer has this in its path. The reason is that its perfectly legal to have a war with just a web.xml, and then have the classes somewher like tomcat/lib. anonymous wrote : | For the testsuite / command line clients I don't think it would be unreasonable to expect the calling client to put all the required jars on the classpath, afterall the wspublish process is not just copying the war it is actually processing the war so the caller should make sure all the required classes are available. | I think that's a reasonable expectation. anonymous wrote : | Alternatively couldn't the tool just copy the war to jbossws-deploy and let the code running within Tomcat handle it? Or even refactor the deployment into it's own servlet and then get wspublish to call the servlet directly to publish the war, again this would mean the deployment would be happening within Tomcat. | The tool was designed so that someone could deploy without the tomcat jbossws deployment service. The http deployment is an option, but its a potential security risk, so it would need to be locked down in some way. Its probably less work to just add a classpath option. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978656#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...