JBAS-3766, port the webservice deployer

[starksm64]

http://jira.jboss.com/jira/browse/JBAS-3766

The webservice deployer is now broken in head as the deployers it depends on have been ported to the the new VDF.

We certainly are sufficiently far along to begin the migration of the webservice deployer to the VDF. However, the tomcat deployer and jbossweb itself probably are not sufficiently refactored to allow the webservice deployer to manipulate the metadata model derived from the web.xml/jboss-web.xml rather than trying to manipulate the war descriptors. That is where we need to get to though.

[jason.greene]

On this topic, I have created an issue for XML overrides that will need to pull from the new metadata model

http://jira.jboss.com/jira/browse/JBWS-1309

-Jason

[starksm64]

The JBAS-3812 issue is related to the current war deployer hack I'm adding to unpack all wars. I see that there is a notion of an unpacked war already that the jbossws deployer must be doing:

 // FIXME: JBAS-3812 - TomcatDeployment should use modified WebMetaData
 URL warURL = (URL) di.getAttachment("jbossws.expanded.war.url");
 if (warURL == null)
 warURL = di.getDeploymentContext().getRoot().toURL();

what I wanted to do here was to look at using an alt-dd value. Instead of having the jbossws deployer creating another expanded war, can it just create an alternate web.xml that the war deployer can pass into tomcat?

[jason.greene]

Sure, I can make the changes after there is support for it. How should I pass the value, as an attachment?

-Jason

[starksm64]

I'm thinking it should just be an attribute in the WebMetaData object. When I get a jbossas testcase working for this I'll let you know.

[starksm64]

Another issue I'm seeing with the current JAXWSDeployerJSE is that it is trying to use the deployment class loader before the class loading deployers have committed. The JAXWSDeployerJSE should be before the WarDeployer, not just after the JBossWebAppParsingDeployer as use of the deployment class loader requires the deployer to be after the CLASSLOADER_DEPLOYER. I created a JBoss5VDFDeployerOrdering page as a reference for how to choose the deployer relative order:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5VDFDeployerOrdering

It has also hard-coded its order so it cannot be overriden at the deployer descriptor level (http://jira.jboss.com/jira/browse/JBWS-1358). We need to remove this so any ordering issues can be corrected outside of the code.

[jason.greene]

Another issue I'm seeing with the current JAXWSDeployerJSE is that it is trying to use the deployment class loader before the class loading deployers have committed. The JAXWSDeployerJSE should be before the WarDeployer, not just after the JBossWebAppParsingDeployer as use of the deployment class loader requires the deployer to be after the CLASSLOADER_DEPLOYER. I created a JBoss5VDFDeployerOrdering page as a reference for how to choose the deployer relative order:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5VDFDeployerOrdering

I took a look at fixing this, but the classloader constructed by the deployer fails because the jar url returned from the VFS refers to "!/WEB-INF/classes instead of "!/WEB-INF/classes/".

See the follow post for more info:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985315#3985315

-Jason

[starksm64]

Support for an alt-dd specification at the WebMetaData level has been added. The org.jboss.test.web.test.AltDDUnitTestCase illustrates this from the ear application.xml level. The jbossws deployer could just set this directly on the WebMetaData instance before the war deployer runs.

The alt dd needs to be in the unpacked war WEB-INF directory. The WebMetaData specification is treated as a deployment relative path that is first treated as a war WEB-INF path, and then as a path from the root of the top level deployment. This is copied into the expanded war WEB-INF as tomcat needs to see this as an absolute file path currently.

There are changes in both the mc jboss-deployers.jar and tomcat jbossweb.jar to support this.

[jason.greene]

I have completed the deployer modifications. We now use the deployment classloader, and we also pass an altDD.

However, I had to modify AbstractWarDeployer to accept absolute paths.

Since the WS deployer runs before AbstractWarDeployer, the war is not yet expanded, so we would have to modify it based off of whether or not it was expanded. Instead I took the simpler approach and just generate an alt dd in the temp dir, and pass that as an absolute path to the war deployer.

-Jason

[starksm64]

Ok, sounds fine.