I'd prefer something where the core service instance implemented the interface, and was registered for the notification automatically, using logic similar to how Initializable is recognized.
Actually, I'm more picturing this as the responsibility of the service extension point to manage (side note: I'm going to refactor things to have a single implementation of ServiceExtensionPoint and multiple implementations of ServiceModel that plug into the point). So the ServiceModel will register itself for the right events (with the Registry and/or ThreadEventNotifier) and will reinvoke the right Manageable methods on the core service instance. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Christian Essl [mailto:[EMAIL PROTECTED] > Sent: Monday, September 29, 2003 7:04 AM > To: Jakarta Commons Developers List > Subject: Re: [HiveMind] Destroy service > > > Thank you for your intrest and the suggestion of 'Manageable'. > > I agree with you that a `Manageable` Interface, which contains a pair > start/destroy would be cleaner. I did not add the start > method because > there is the Initilizable Interface. As you said very > precisily my service > is an event service (I did not see that so clearly before), but the > Initilizable is not. The Initilizable is managed by the > framework, does not > need user interaction, is called during runtime and the > Service Interface > does not have to implement it. If the methods would be paired up some > (rather small) changes to the framework had to be done. > > Resulting from the event-way I think the biggest disadvantage > of my aproach > is that the destroy method will be always called wheter the > Service has > ever been used or not. While this has the little advantage that it is > possible to implement special shut-down Servies, but generally it is > unneeded (very) resource intensive. The only way I see this could be > changed would be if the ServiceExtensionPoint had a method > isLoaded() (but > this is of course again a framework chance which increses the > interfaces > size). > On Mon, 29 Sep 2003 10:10:30 +0200, Johan Lindquist > <[EMAIL PROTECTED]> > wrote: > > > Definately interested in a service such as you describe - life-cycle > > events has been chucked around in the group for a bit and I > think it > > would be a valueable service. > > > > Any chans of changing it [the interface] to (perhaps) > 'Manageable' to > > allow for future 'start' events too or would it be too much > to put it all > > into one interface? > > > > Regards, > > > > Johan > > > > On Sun, 28 Sep 2003 23:46:14 +0200, Christian Essl > > <[EMAIL PROTECTED]> wrote: > > > >> I've written a Service which registers Destroyable Services (a > >> special > >> interface which must be implemented by the > service-interace) and keeps > >> dependencies between Services. When the application using > a Registry > >> shut-downs (and no other thread is using the Registry > anymore) it calls > >> on the Service destroy() and the Service will call the > destroy() methods > >> on all the registered Services in the right order. > >> > >> This helps me in my project to easier maintain the right shut-down > >> for > >> Services which need information about ie when they should release > >> resources. > >> > >> Currently the dependencies and registration of the Services happens > >> through contributions. However when Howard makes it > possible to get the > >> Shema and I can implement a ConfigurationBeanFactory I think of > >> implementing a special rule and transformer which > automaticly registers > >> a dependend/destryable object when the user creates one or > gives it to > >> aother service. This would free the user of a > service-implementation of > >> filling in the dependency-contribution, which is of course > error-prone. > >> > >> Is there any intrest in such a Service to be included in HiveMind? > >> > >> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > > > > -- > Using M2, Opera's revolutionary e-mail client: > http://www.opera.com/m2/ > > > --------------------------------------------------------------------- > 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]
