JBWS-1093 - normal servlets the web.xml is modified as if th

[dlofthouse]

Originally before the support for Tomcat was added to JBossWS the process of modifying the web.xml was implemented to only modify the servlet entries in the web.xml if the servlet was actually a web service.

For JSR-109 deployments web services were identified by the presence of the 'servlet-link' in the webservices.xml, for JSR-181 deployments this was identified by checking if the class has the @WebService annotation.

I believe this is still the correct mechanism to identify if the servlet is supposed to be exposed as a web service.

For deployments deployed to JBoss from the UnifiedMetaData we can get the list of all of the servlet-links so this could be passed into the 'rewriteWebXML' method to be used to identify which servlets need to be converted.

For Tomcat deployments we do not have this information available at the moment. For JSR-109 deployments I think we just need to parse the webservices.xml to get the list of servlet-links.

For JSR-181 deployments we are going to need a classloader to load the servlet classes to check if they have the @WebService annotation. Because this is not always called from within the container we are going to need to create a classloader so that we can load the classes in the war, I think we should create a URLClassLoader so we can add all of the jars in the war and the classes folder in the war. The parent of the URLClassloader should be set to the current classloader at the time it is created.

[jason.greene]

The issue with tomcat is that there isnt a classloader or even a parent clasloader available at this time in the process. Basically we need to create a classloader that follows the tomcat classpath.

-Jason

[dlofthouse]

For Tomcat I see there are two/three different paths that can lead us to rewriting the web.xml

The class TomcatServiceEndpointPublisher starts a scanning thread to periodicaly check the JBossWS deploy folder, if a new archive is found this will cause the archive to be processed and the web.xml to be rewritten.

I cant get JBossWS to deploy to Tomcat at the moment to test this out but as the scanner thread is already running within Tomcat shouldn't it already have a classloader?

The second/third parth is when the deployer is called from the testsuite or when it is called from the command line, in this scenario the only classloader we have is the system classloader. This classloader should still have the JBossWS classes on the classpath.

The only time we really need the classloader is to load the classes of the endpoints to check if the class is annotated with @WebService. What else do you see us needing available on the classpath?

[dlofthouse]

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.

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.

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.

[jason.greene]

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.

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.

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

[dlofthouse]

I believe the CrossContextLoader I have available was created using the StandardClassLoader of the jbossws web application as the parent classloader so by using this we should have access to all of the classes within jbossws as well as all of the Tomcat libs.

I think my priority for this should be:-

- Deployment from within JBoss
- Deployment from scanner thread in Tomcat
- Deployment from testsuite

For command line clients we can say it's the clients responsibility to include all the required jars on the classpath (we will just need to make the jars and classes in the war available).

If we want to consider refactoring the wspublish to take advantage of the deployment from within Tomcat we can look at that later.

[thomas.diesler]

I'll fix JBossWS/Tomcat standalone.

[dlofthouse]

Its Ok I already fixed that last night (JBWS-1305), I haven't run the testsuite against it yet but I have deployed a web service and can access it's WSDL without error now.