Resolving issue JBAS-1801

[starksm64]

Background:

http://jira.jboss.com/jira/browse/JBAS-1801
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64874

We need to move toward url handling being a vfs aspect of the deployment layer. In the interim, we need to cleanup the subdeployment processing in 4.0.x to avoid inconsistencies in behavior as new deployers are added.

Repeating the forum reference statement, most deployers can rely on the packing/unpacking done by the MainDeployer/Subdeployment support layers and should not have to worry about details of whether they can handle an archive or a directory as the DeploymentInfo.localUrl and localCl should be configured correctly for them. Deployers like the ear and war deployers are the problems since they have non-trivial heiarchical structures.

I think the main problem with consistency right now is the ear deployer's notion of overriding the subdeployment processing. First, the list simply needs to be externalized. Beyond that, the notion of restricting subdeployments to the application.xml jars is broken because we allow arbitrary subdeployments to be introduced via the jboss-app.xml descriptor.

We should just be checking the subdeployment against the list of archives specified via the application.xml or jboss-app.xml descriptors. Really, I don't think we care at all about the suffix, so the externalization of acceptable suffixes is should be irrelevant.

[adrian.brock]

So the main issue is to fix the ear deployer to only accept the explicitly
defined modules in application.xml and jboss-aop.xml

If that is correct, I'll create a subtask off JBAS-1801 and fix it myself.

I think that whether the explicitly named deployment actually has an installed deployer
is not an issue relevent to the EARDeployer. It will try to deploy the subdeployment
and it might fail if no installed deployer recognises it.

I'm not sure I get the issue with the war deployments since they don't accept
any subdeployments? Or has that changed?

[starksm64]

No, that is correct, the war deployer does not have a subdeployment notion currently. We did waffle a bit when adding web services, but ultimately the integration went into the tomcat deployer.

The issue with the war is that it does need to know more about its deployment structure to properly configure the myriad of paths tomcat needs and navigation depends on whether there is a packed/unpacked deployment.

I do think the only real issues are to fix the hard coded subdeployment list in the ear deployer, and then to push the accepts implementation to the subdeployer support level based on the directory free list of suffixes the subdeployer implementation supports. So given a .jbar, and a -bean.xml deployment suffix list, ".jbar", ".jbar/" and "-bean.xml" are accepted by the bean deployer.

[starksm64]

Also note that the inclusion of the '.' and '-' in the suffix is important as there has been some supurious deployment exceptions when unqualified suffixes were found, for example, "notajbar" getting deployed as a ".jbar".

[adrian.brock]

OK, I'll fix the EAR deployer.

The other issue would be things like the rar deployer not including the "."

 public String getExtension()
 {
 return "rar";
 }

in its checking.