1 Reply Latest reply on Apr 11, 2007 10:18 AM by Adrian Brock

    Deployers Reloaded

    Adrian Brock Master

      This is an informational post. If you want to discuss specific topics
      raised here, please create a seperate thread rather than creating another
      unreadable monster thread. :-)

      Its been over three months since I left the deployers framework
      for you guys to get on with trying out.

      I think that's sufficient time for you come up with usecases.

      I'm now going to rework the deployers in the light of what has been discovered
      and some extra requirements, some are experimental, others not.


      We need to create the proper abstractions over the DeploymentContext.
      The DeploymentContext (a replacement for the horrible DeploymentInfo)
      was only ever intended as an internal booking device
      to tie the four different views of the data together.

      1) Client view - the person requesting the deployment
      2) Management view - the managed objects
      3) Structure view - Scott already made a start on this
      4) Deployer view - the DeploymentUnit

      The DeploymentInfo was horrible because it leaked implementation details
      into all sorts of code and nobody knowed whether the information was
      being updated consistently.

      The purpose of the abstractions is to ensure that the internal model is exposed
      consistently to the deployers.
      Exposing DeploymentContext on the DeploymentUnit was only ever a hack
      to allow you guys to get on with writing the deployers so we can find out
      what features were missing.


      I need to document the Deployers so that people know what the model means
      and how best to use it. The current AspectDeployer is example where even
      the main idea of how the new deployers is supposed to work or integrate with the
      profile service or other deployers (it has a number of other issues as well :-).


      Top level only deployers - like the classloading deployer, the security deployer(s)
      also want to deal only with the top level deployment, this should be handled more

      Components - this prototype needs completing and like the "top level only" deployers
      there needs to be extra support for deployers that are only or not interested in

      Ordering - most of the deployers are defining their own ordering rather than using the standard (which kind of defeats the point), see later on state machine and attachment streams.



      Russian doll, etc. - Scott has expressed a requirement to have the old implicit
      deployment rules. This should really be a pluggable policy. Ideally, we should be
      able to also implement an "all or nothing" deployment rule as well rather than the
      current rules where parts of an EAR get deployed because there is explicit rule
      to stop them (or they are out of order because implicit rules in general don't work).


      Currently a deployment will go through all deployers. The deployer is expected
      to do something like:

      public void deploy(DeploymentUnit unit)
      MyMetaData md = unit.getAttachment(MyMetaData.class);
      if (md == null)
      // do stuff

      Ideally, we should be able to expose this information such that the deployer
      is never called if there is no such attachment(s).
      Similarly the output should be definable so the "main deployer" can order the
      "stream". e.g.
      nothing => ParsingDeployer<DeploymentMetaData> => DeploymentMetaData => ComponentDeployer<DeploymentMetaData, ComponentMetaData> => ComponentMetaData => RealDeployer<ComponentMetaData>


      Part of the OSGi work requires classloading dependencies (at both package
      and deployment level). For non-OSGi deployments this will be definable via
      jboss-classloading.xml, i.e. export, import, dynamic import and uses
      (See the OSGi spec for what those are).

      This means that the deployments themselves will have dependencies
      so I'm going to introduce the Microcontainer dependency mechanism
      into the MainDeployer to handle this.
      In some sense, this also removes some of the ordering problems
      since the currently defined standard ordering will be replaced with

      I think the combination of assigning well defined states when deployers get run,
      coupled with the attachment streams should handle most cases, but I'm
      still going to keep the deployer ordering for use cases where this might
      not be enough to resolve the ambiguity (assuming the order matters? :-).


      I don't see any of the new features being used by the deployers in JBossAS
      or JBoss Embedded having corresponding tests in the JBoss Deployers project.

      How you guys expect this not to regress is beyond me?

      I'm going to abstract out what I think are the features intended and create
      tests for them. I'm not going to create tests for what I think is just broken usage. ;-)

        • 1. Re: Deployers Reloaded
          Adrian Brock Master

          Forgot one other requirement.


          Each deployment should be automatically assigned a "scope" which should then
          be used to tie the deployment and JMX/POJO contexts together.

          e.g. The deployment might a scope:


          A subdeployment the scope


          An MBean created for this deployment


          The rules to create these scopes will also allow a scoped metadata deployer
          to be written, e.g. load additional contextual metadata from a jboss-meta.xml
          and also tie into the scope/naming rules for JSR77.