> > 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?
Perhaps... though I think that a different aproach (other than plugging in a different impl) would solve these problems. Like I said, lets gather requirements and desired features and design the system as a whole. > The point is I can see no down-side to > making this pluggable, and it is a very easy patch. Perhaps, though I think it is a hack around an already deficent system... notifications for triggering emails, jmx interceptors for security... If we are going to spend time, lets spend that time and fix it not add to the hacks. > More important, though, > is to prevent SubDeployers from accessing MainDeployer specific > functionality. That is just bad design. I don't understand what you mean here... though I have an idea. I am not sure this system has had much design put into it... rather it is a collection of patches/hacks/whatever which have grown off of the 2.0 rewrite... though I have no evidence to support that really. > > 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? The Deployer & SubDeployer interfaces are realitivly new. I put this change in so that I could use the Deployer interface for chaining components together from a DS to MD. Deployer has deploy(URL), undeploy(URL) and so on, so I am not sure why you mention lastDeployed and such... The NetBoot cache components sit inbetween a DS (say URLDeploymentScanner) and MainDeployer performing local caching of urls. This allows the server to startup faster when using NetBoot, once it has created initial cached deployment urls. It is probable that once JMX interceptor stacks are configurable that we can replace this with a caching interceptor around a DS. * * * I think that with all of the proposed designs that we probably have enough information to start a rough requirements doc this deployment, possibly even start to tie down the major logical components which need to be involved. --jason ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
