Hi, In general, I find the RegistryShutdownListener stuff in HiveMind insufficient for serious purposes. It would be a great add-on to be able to order the calls to the Listeners so that some services can call other services as part of their "shutdown" process, the current problem is that if A depends on B for shutdown, and if BOTH A and B are RegistryShutdownListeners, then you can never be sure that A can call B on shutdown because B may have shutdown already...
I have this kind of problem in HiveUtils (and in HiveBoard which uses HiveUtils): I use the "hiveutils.AsynchronousTaskPerformer" service to defer DB updates through hivetranse service. AsynchronousTaskPerformer has to make sure that all pending tasks are flushed to DB when the system (thus the Registry) shuts down, hence it is a RegistryShutdownListener. However, hivetranse also has some cleanup to perform on system shutdown... You see the problem? For me this is a design flaw (no flames please). At the minimum, Registry shutdown should proceed in 2 steps "before" and "after". The idea would be that as long as you are "before", the Registry is still alive, and you have a chance to use any service. After "after" (;-)), the Registry HAS shut down, and any call to another service would not be safe. Of course, it would be possible as well to order shutdown listener the same as the ordering we have already for interceptors, not a problem, and even one advantage: it does not break code compatibility. I would really _love_ to see such improvement in the 1.1 branch (I don't want to feel obliged to switch to JDK5;-)) Cheers Jean-Francois -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 5:29 PM To: [email protected] Subject: RE: 1.1.2 Release... Johan, I seem to remember this conversation now. With the refactoring that I'm proposing (getting injection for free) in HiveMind 2.0, the "init method" would become part of the "assembly instructions." I don't know about the shutdown method, though. Maybe we could make the RegistryShutdownListener something that's internal. James -----Original Message----- From: Johan Lindquist [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 3:38 AM To: [email protected] Subject: Re: 1.1.2 Release... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Yes, deprecation would of course be the way to go - a little to hasty in my wording. In any case, I think you and I discussed this earlier - just like the initializeService method is the default name of the method to call when starting a service, the registryDidShutdown method would work in similar fashion. I do know that currently, the registry shutdown is tied to the service model and that the initializeService is tied to the builder factory. The problem I guess is how to propagate which method is to be used when the registry shuts down. This could be added to the builder factory, but not sure if that is the correct approach. As for the other, no worries - think I am looking for those feature for use within my project and therefore the strive to get them in ;) Cheers, Johan James Carman wrote: > Johan, > > What do you propose instead of the RegistryShutdownListener? We can't just > remove it. We would have to deprecate it for some time before we just pull > the rug out from under our users. > > As for the other requests, they are enhancement requests (I know, my > parameterIndex was an enhancement, but needed by Tapestry). I am looking > for more bug-releated requests. We should definitely look into the > enhancements you mention for 1.2 (and of course 2.0). > > James > > -----Original Message----- > From: Johan Lindquist [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 14, 2006 2:30 PM > To: [email protected] > Subject: Re: 1.1.2 Release... > > Hi, > > I have mentioned it before - and it's probably turning into a rant for you > all ;) - but I'd like to see conditional sub-modules, ordering of eager > loaded services and possibly even removal of the RegistryShutdownListener > interface in the next version. > > Thanks, > > Johan > > >> All, >> >> Is there anything that you folks think we should additionally include in a >> 1.1.2 release? I have added something today (StrategyFactory now allows >> you >> to specify which parameter is used to pick a strategy). >> >> James >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - -- you too? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkQ5K1Tv8wj7aQ34RAkxJAJ4zfnc2ZRQURX/jrEWNGcT+ZDuY6QCfamGY MXSe9gLZuZHE/gnMizRIW68= =cK0W -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
