"adrian(a)jboss.org" wrote : 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); | | } | | | IMO, there's just too much implicity in both the old and new deployment architecture. My experience writing the first deployer in this new architecture was that I had to dive through a lot of internal code to figure out what the hell was going on. It seems like this is getting worse with the new refactoring you did. I honestly don't care about saving one line of if attachment exists code. It actually makes the code more readable and more importantly, more understandable for people using your deployer as an example for writing their own. 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@39471b for stage Real | org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer(a)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(a)1e46a68{inputs=[org.jboss.beans.metadata.spi.BeanMetaData] outputs=[]} | org.jboss.deployment.ClientDeployer@39471b{inputs=[] outputs=[org.jboss.metadata.ClientMetaData]} | org.jboss.deployment.security.SecurityDeployer@18b4ccb{inputs=[] outputs=[jboss.jacc]} | org.jboss.ejb.deployers.EjbDeployer(a)5e5c15{inputs=[org.jboss.metadata.ApplicationMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.ejb3.deployers.AppClientScanningDeployer(a)1743ff4{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] | } | org.jboss.ejb3.deployers.EJBRegistrationDeployer@d1afd3{inputs=[] outputs=[org.jboss.ejb3.Ejb3Deployment]} | org.jboss.ejb3.deployers.EJBStage2Deployer(a)1ee2ea8{inputs=[org.jboss.ejb3.Ejb3Deployment] outputs=[]} | org.jboss.ejb3.deployers.Ejb3ClientDeployer(a)182b9b5{inputs=[org.jboss.ejb3.metamodel.ApplicationClientDD] outputs=[org.jboss.ejb3.clientmodule.ClientENCInjectionContai | ner]} | org.jboss.resource.deployers.RARDeployer(a)f04dae{inputs=[org.jboss.resource.metadata.ConnectorMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.web.tomcat.service.deployers.TomcatDeployer(a)133926{inputs=[org.jboss.metadata.WebMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.system.deployers.ServiceDeploymentDeployer(a)1b7c76{inputs=[org.jboss.system.metadata.ServiceMetaData, org.jboss.system.metadata.ServiceDeployment] outputs=[or | g.jboss.system.metadata.ServiceMetaData]} | org.jboss.system.deployers.ServiceDeployer(a)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=4058932#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...