[jboss-dev-forums] [Design the new POJO MicroContainer] - Attachment Flow

[adrian@jboss.org]

The next form of dependency is something I described when I first wrote the
deployers.

i.e. it should be able to work out what order to process the deployers
from what information you input/output.

Most of this can be done automatically, e.g.


  | public class MyDeployer extends AbstractSimpleRealDeployer<MyMetaData.class>
  | {
  |    public MyDeployer()
  |    {
  |        super(MyMetaData.class);
  |    }
  | }
  | 

Will automatically know that you want MyMetaData attachments.

As an aside, with those classes, it will also know that you don't want to be
invoked for deploy/undeploy if there is no such attachment.
i.e. no longer any need for the boiler place

  | if (unit.getAttachment(MyMetaData.class) == null)
  |    return;
  | 
If you don't want this filtering, you can turn it off with

  |    public MyDeployer()
  |    {
  |        super(MyMetaData.class);
  |        setAllInputs(true);
  |    }
  | 

But back the attachment flow. You can also be explicit about
what other information you want. i.e. what deployers should be before/after you.

e.g.

  |    public MyDeployer()
  |    {
  |        super(MyMetaData.class);
  |        setInputs(SomeOtherMetaData1.class, SomeOtherMetaData2.class);
  |        setOutputs(MyOutput.class);
  |    }
  | 

You can see this in the DEBUG where it shows the calcualted ordering
and input/outputs, e.g.

  | 2007-06-28 14:34:27,112 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] Added deployer org.jboss.deployment.ClientDeployer at 39471b for stage Real
  | org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer at 121df2a{inputs=[org.jboss.beans.metadata.spi.BeanMetaData, org.jboss.kernel.spi.deployment.KernelDeplo
  | yment] outputs=[org.jboss.beans.metadata.spi.BeanMetaData]}
  | org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer at 1e46a68{inputs=[org.jboss.beans.metadata.spi.BeanMetaData] outputs=[]}
  | org.jboss.deployment.ClientDeployer at 39471b{inputs=[] outputs=[org.jboss.metadata.ClientMetaData]}
  | org.jboss.deployment.security.SecurityDeployer at 18b4ccb{inputs=[] outputs=[jboss.jacc]}
  | org.jboss.ejb.deployers.EjbDeployer at 5e5c15{inputs=[org.jboss.metadata.ApplicationMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
  | org.jboss.ejb3.deployers.AppClientScanningDeployer at 1743ff4{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.metamodel.ApplicationClientDD]
  | }
  | org.jboss.ejb3.deployers.EJBRegistrationDeployer at d1afd3{inputs=[] outputs=[org.jboss.ejb3.Ejb3Deployment]}
  | org.jboss.ejb3.deployers.EJBStage2Deployer at 1ee2ea8{inputs=[org.jboss.ejb3.Ejb3Deployment] outputs=[]}
  | org.jboss.ejb3.deployers.Ejb3ClientDeployer at 182b9b5{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.clientmodule.ClientENCInjectionContai
  | ner]}
  | org.jboss.resource.deployers.RARDeployer at f04dae{inputs=[org.jboss.resource.metadata.ConnectorMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
  | org.jboss.web.tomcat.service.deployers.TomcatDeployer at 133926{inputs=[org.jboss.metadata.WebMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]}
  | org.jboss.system.deployers.ServiceDeploymentDeployer at 1b7c76{inputs=[org.jboss.system.metadata.ServiceMetaData, org.jboss.system.metadata.ServiceDeployment] outputs=[or
  | g.jboss.system.metadata.ServiceMetaData]}
  | org.jboss.system.deployers.ServiceDeployer at 147e668{inputs=[org.jboss.system.metadata.ServiceMetaData] outputs=[]}
  | 

You'll notice the Service deployer is after many of the other deployers that create
ServiceMetaData (even though it was one of the first deployers deployed).

NOTE: The old relativeOrder still exists, but it is probably not as a good a way
to determine ordering.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058844#4058844

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058844