Menu
▾
▴
Re: [JBoss-dev] Deployer design
|
From: Jules G. <Jul...@ya...> - 2002-04-17 22:00:10
|
Sacha Labourey wrote: > Hello, > > For the redeploy thing, I agree with Jules: it is very important to have such a semantic. And as David said, to be properly done, it must be handled at the MBEAN-interceptor level because the redeploy may change the list of interceptors => setting this in a container interceptor is not a definitive option. Agreed, it ia likely to be functionality required at a number of levels - each one needs to be given the chance to implement it. Jules > > Nevertheless, Just for your information, I've implemented (for the clustering), yesterday, a CleanShutdownInterceptor that, at least, allows for clean shutdown of a containers by making wait the stop call until all running invocations are done (all new invocations are redirected to another node of the cluster.) > > Cheers, Nice ! > > > Sacha > > > >>-----Message d'origine----- >>De : jbo...@li... >>[mailto:jbo...@li...]De la part de >>Larry Sanderson >>Envoyé : lundi, 15 avril 2002 02:44 >>À : jbo...@li... >>Objet : Re: [JBoss-dev] Deployer design >> >> >> >>>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. >> >>I can find the time, but I think I am the least experienced JBoss user / >>developer on this thread. Once I have something to post, I will >>need a lot >>of feedback. I'll let you know when I have something. >> >>-Larry >> >> >>>--jason >>> >>> >>>Quoting Larry Sanderson <lsa...@sp...>: >>> >>> >>>>>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 >>>>Jbo...@li... >>>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>>> >>> >>> >>> >>> >>>------------------------------------------------- >>>This mail sent through IMP: http://horde.org/imp/ >>> >>>_______________________________________________ >>>Jboss-development mailing list >>>Jbo...@li... >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >> >>_______________________________________________ >>Jboss-development mailing list >>Jbo...@li... >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > > > _______________________________________________ > Jboss-development mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-development > |