>
>
> [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
> >
> > [...]
> >
> > public interface Service {
> > public void load(ServiceContext context) throws Exception;
> > public void start() throws Exception;
> > public void stop() throws Exception;
> > }
>
> I keep going back and forth between two ideas: the first one
> is the above
> one, where a service is simply tied to the JVM process.
> Basically, when the JVM process is created, load(...) then start() are
> called, and at shutdown stop() is called.
>
> Another idea would be this one:
>
> public interface Service {
> public void init(ServiceContext context) throws Exception;
> public void start() throws Exception;
> public void stop() throws Exception;
> public void destroy() throws Exception;
> }
>
> This differs from the first one _not_only_ because a new
> method is added,
> but also because the lifecycle of a Service is different: when the JVM
> process is created init() is called (instead of load, but
> it's the same
> shit), destroy() is called before the VM process is shut
> down, but start()
> and stop() simply imply that a Service could be started and
> stopped many
> times within the life of the JVM process...
>
> So, now I'm stuck. Which one do you think is better (lately, I'm more
> oriented towards the second approach!)
>
> Pier
>
i kind of like the second approach.
i like the idea, for example, of being able to tweak a config file, then
restart a service without having to restart the entire vm.
also, it has nice symmetry with the servlet api :)