True, but if you ever find that a "ReloadAware" service needs to be aware of "startupOnReload" or some such, then you either have to craft a new interface (confusing, since this interface is "ReloadAware"...) or add the method to this interface (yuck: not backwards compatible, and services that need one or the other are forced to implement both). I think the name of this interface could be better crafted. Perhaps "UnloadAware" or some such? Then if we found the situation of a service needing to know what it was re-loaded, we could add a "LoadAware" or some such.
Just a thought. Robert On Oct 1, 2010, at 10/12:00 PM , Howard Lewis Ship wrote: > I thought about that, but this is a situation rare enough that an > annotation doesn't provide enough bang for the buck. > > On Fri, Oct 1, 2010 at 11:39 AM, Thiago H. de Paula Figueiredo > <[email protected]> wrote: >> On Fri, 01 Oct 2010 15:28:35 -0300, Howard M. Lewis Ship (JIRA) >> <[email protected]> wrote: >> >>> I see this as an optional interface that could be implemented by a service >>> implementation (or, for that matter, an non-service proxy object): >>> >>> public interface ReloadAware >>> { >>> void shutdownInstanceBeforeReload(); >>> } >> >> What about an annotation in a no-args method instead? >> >> -- >> Thiago H. de Paula Figueiredo >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and >> instructor >> Owner, Ars Machina Tecnologia da Informação Ltda. >> http://www.arsmachina.com.br >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > 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]
