YADD (Yet Another Deployer Design)... comments below. > I see two major problems with the current usage: 1) MainDeployer is a > bootstrapped class, with no way to provide an alternate implementation, 2) > All SubDeployers rely on a concrete implementation of deployer: MainDeployer,
Why do you need another impl of MainDeployer. This component serves to aggregate SubDeployers and to provide a common interface for clients into the deployment system. It might be doing a little much at the moment (I haven't looked at what the code looks like this week), but from a concept pov there is no reason to make this pluggable. > The second problem is not so easy. I propose that we give more control to > the SubDeployers, and simplify the bootstrap deployer. I propose that we > move all life-cycle management of SubDeployers to the particular > implementations of SubDeployer. This eliminates the need for the bootstrapped > deployer to manage each SubDeployer's life cycle. Further, the bootstrapped > deployer no longer has to manage DeploymentInfo objects - this job has been > passed down to the SubDeployer as well. This allows each SubDeployer to > create their own implementations of DeploymentInfo. Finally, DeploymentInfo > needs to be cleaned up - it has become a repository for disparate, and often > unnecessary information. Since SubDeployers are now allowed to create their > own implementations, all but the most common attributes can be removed. This is reminicent of the design I proposed several months ago (DeploymentManager, DeploymentFactory, Deployment & friends): http://main.jboss.org/thread.jsp?forum=66&thread=8288 > Here are my thoughts for the public class structure: > > [code] > public interface SubDeployer > { > boolean accepts(URL url); > boolean deploy(URL url); > boolean unDeploy(URL url); > boolean isDeployed(URL url); > DeploymentInfo getDeploymentInfo(URL url); > } > > public interface Deployer extends SubDeployer > { > SubDeployer getSubDeployer(URL url); > void addDeployer(SubDeployer deployer); > void removeDeployer(SubDeployer deployer); > } > [/code] Note, that this change will invalidate the Deployer usage which is needed for DeploymentScanner (including NetBoot caching components). That doesn't mean those components can not change to adapt to new designs, but it seems like your design is not taking this into account. > Let me know if you have any comments. I would like to get started on this > soon. I think we need to think hard about the requirements of the deployment system... look at the current use cases and those we invision for the future before we start redesigning this critical subsystem again. This is definetly not going to happen for 3.0, perhaps 3.1-3.2. We really need to get this crap down right... we seem to change this every few weeks, which just causes trouble for those who rely on how it works, those who write documentation for it & those who provide components around it. Let us take some time to get this done right... then leave it alone. --jason ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
