[jboss-dev-forums] [Design of POJO Server] - Hot deploying deployers - deployer chains

Rather than having a single deployer chain, what we really need is a tree like structure based on the input/output of the metadata structures. e.g. | -- one-to-one | -< one-to-many | \- additional branch | | Services | -service.xml -- ServiceDeployment.class -< ServiceMetaData.class -- MBean | \- LoaderRepositoryConfig.class - ClassLoader | | Rars | .rar -- RARMetaData.class -- ServiceMetaData -- etc. | \- LoaderRepositoryConfig.class -- etc. | | Connection factories | -ds.xml -- ServiceDeployment.class -- etc. | \- LoaderRepositoryConfig.class -- etc. | With each deployer defining its inputs and outputs. e.g. SARDeployer input = -service.xml output = ServiceDeployment.class ServiceDeploymentDeployer input = ServiceDeployment.class, ServiceMetaData.class output = ServiceMetaData.class ServiceDeployer input = ServiceMetaData.class output = REAL This way the chain can built up based on the input/outputs. We still need the original relative ordering to decide which parts of the chain of get done at what stage, e.g. the ServiceClassloaderDeployer is done before the ServiceDeploymentDeployer The advantage to this, is that we know when a deployer is added whether other deployments (really pieces of their metadata) are affected. i.e. whether we need to unwind them to reprocess something. e.g. When I add the RARDeployer to the beginning of the chain I only need to see what deployments are rars (end in .rar or have a ra.xml) and process the output ServiceMetaData through its particular chain. e.g.2. If somebody interpolates a deployer that processes ServiceMetaData.class between the ServiceDeploymentDeployer and the ServiceMetaDataDeployer then I need to unwind the work of the ServiceMetaDataDeployer to do that work before winding forward again. Such a mechanism also gives a more direct link for the front end profile service to reprocess part of a deployment (including just changing an attribute on an MBean if that is all the update requires - i.e. no redeploy). The big stumbling block, comes from things like: -aop.xml -security.xml log4j.xml where we don't want any (or maybe part) of the deployment to proceed until these have established their context. But if these are hotdeployed, how do we know they even exist? One solution is to be able to define these "show stoppers" in the main deployer or profile service metadata. However, that still leaves the age old problem, how do I apply a -security.xml to the security deployer? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972529#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...