3 Replies Latest reply on Sep 29, 2006 7:35 AM by Adrian Brock

    Deployment Structure

    Adrian Brock Master

      This is a summary to try to end the discussions that are currently going
      around in circles.

      The basic idea follows the "do one thing well principle".

      There are three components:
      1) VFS - responsible for presenting the different protocols as a
      single consistent file system, and abstracting away things like
      unpacked directories pretending to be jars or unpacking nested jars.

      2) StructureDeployers - responsible for determining the structure
      of deployments, i.e. what is the classpath, metadata location
      and subdeployments.

      3) Deployers reponsible for working with the above models
      to deploy stuff.

      In no way should:
      1) The VFS be dealing with deployment decisions.
      2) The structure deployers be dealing with protocol issues.
      3) The real deployers be dealing with protocol or structural issues.

      I can think of one current exception to this rule where the
      jboss-service.xml has an

      <archives/>

      that adds additional elements to the classpath.

      In future, there is likely to be some form of aspectized
      classloader.xml that will take the place of this element
      and the loader-repository-config which can be processed by
      the structure deployers such that this can be deprecated
      and removed as the legacy mixing of concerns that it is.

        • 1. Re: Deployment Structure
          Scott Stark Master

          I agree, but I don't think the current interaction between 1 and 2 is adequately defined. I believe I should be able to attribute the path /projects/web/test-web-app as a war in the vfs. This does provide a context for war related deployment analysis, but its neccessary.

          Otherwise, I don't see how a structural deployer will be able to identify that /projects/web/test-web-app/test.jsp is a war with a single jsp file.

          • 2. Re: Deployment Structure
            Bill Burke Master

            I have a possible problem with #3. Take EJBDeployer. I need to be able to identify whether the EJBContainer is deployed within an EAR as apposed to being deployed within a super JAR (jar that has other jars) or a SAR or some other non-scoping entity. I need this to be able to generate the kernel name of the EJBContainer (ear name + jar name) and default JNDI name.

            I guess what I could just do is scope the name if the DeploymentUnit.getDeploymentContext().getParent() is not null. The deploy/ directory is not considered a DeploymentContext/Unit, right?


            • 3. Re: Deployment Structure
              Adrian Brock Master

               

              "bill.burke@jboss.com" wrote:

              I guess what I could just do is scope the name if the DeploymentUnit.getDeploymentContext().getParent() is not null. The deploy/ directory is not considered a DeploymentContext/Unit, right?


              No, there should be a
              public interface DeploymentUnit
              {
              ...
              DeploymentUnit getParent();
              }
              


              The getDeploymentContext() is only there so you can get on with
              doing things while we work these details out.

              It's upto you. You can either use the DeploymentContext,
              and I'll fix it later, or you can change the DeploymentUnit now
              if you think something is generically useful.