> 
> 
> [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 :)

Reply via email to