4 Replies Latest reply on Jun 6, 2005 2:03 PM by adrian.brock

    Resolving issue JBAS-1801

    starksm64
    starksm64 Jun 6, 2005 12:38 PM

      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.

      • 64389 Views
      • Tags:
        • 1. Re: Resolving issue JBAS-1801
          adrian.brock Jun 6, 2005 12:56 PM (in response to starksm64)

          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?

            • Actions
          • 2. Re: Resolving issue JBAS-1801
            starksm64
            starksm64 Jun 6, 2005 1:09 PM (in response to 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.

              • Actions
            • 3. Re: Resolving issue JBAS-1801
              starksm64
              starksm64 Jun 6, 2005 1:18 PM (in response to 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".

                • Actions
              • 4. Re: Resolving issue JBAS-1801
                adrian.brock Jun 6, 2005 2:03 PM (in response to starksm64)

                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.

                  • Actions