commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [VOTE] [daemon] Moving to commons proper
Date Wed, 14 Aug 2002 09:33:34 GMT wrote:
> On Tue, 13 Aug 2002, Remy Maucherat wrote:
>>The daemon component is reaching a point where it starts to be mature 
>>and provide useful services. It is also in use in the upcoming Tomcat 5 
>>I propose that daemon is moved to commons proper, and steps are taken to 
>>eventually release a 1.0 version based on that code.
>>+1 [ ] Yes, move daemon to commons
>>-1 [X] No, because:
> Deamon is yet-another lifecycle interface. I don't think this is right for
> [pattern], nor [discovery] - and same arguments apply to daemon. 
> I'll change my vote to +1 if the interface is droped and introspection
> is used.  

Ok, but the Daemon interface isn't that trivial beacuse of the init 
method (it allows getting a callback to the controller).

BTW, I have no idea if all that is useful or not; all I did here is take 
the Service interface Pier wrote, and rename it Daemon.

It seems it would be relatively low impact to change/remove the 
ineterface now.
Since you voted -1, I hope you have some ideas to do that ;-)

Here's my view on the subject (using JMX as the base "idea"):

The base for the lifecycle interface is start/stop. That's easy to 
introspect ;-) However, we need more for the port-80-without-root thing 
on Unix, and possibly for other more advanced scenarios.

So we would need also:
- init
- a way to pass parameters (that's useful, unless we decide to go with 
introspection and javabean setters, which works too and is likely a lot 
more JMX friendly)
- destroy can be useful too I suppose
- the callback thing is also useful, since it adds the possibility to 
have callbacks (but JMX has that too, I think)

So we could probably refactor the Java code in commons-daemon using JMX.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message