Perhaps you can take an initial stab on a requirements list for the deployment systen, based on the existing proposals (specifically david's, mine & yours + comments by jules and such).
If you have time it would be helpful to move this work forward. --jason Quoting Larry Sanderson <[EMAIL PROTECTED]>: > > 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. > > I don't know... perhaps someone would like to add a custom layer of > security > on all deployments. Perhaps they would like to get an email when new > deployments occur. Who knows? The point is I can see no down-side to > making this pluggable, and it is a very easy patch. More important, though, > is to prevent SubDeployers from accessing MainDeployer specific > functionality. That is just bad design. > > > 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. > > I'm not sure what you mean here. By Deployer usage do you mean > lastDeployed > and lastModified? I had planned on leaving these in the DeploymentInfo > object. What are NetBoot caching components? > > > > > 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. > > I agree. Thanks for your feedback. > > -Larry > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
