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 20:23:43 GMT wrote:
>>Ok, but the Daemon interface isn't that trivial beacuse of the init 
>>method (it allows getting a callback to the controller).
> Deamon.getDeamon() to get the controller. 
> But I don't think deamon should be used this way - JSR77 is
> one way to start/stop components, or whatever the launched 
> program wants to use ( avalon or any other API )

I'm not completely sure the controller is needed.

>>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)
> What about:
>   1. look for a method 
>         static init(String args[] ) ( or preMain( String [] ) ?
>      if found, call it, then switch the UID - the code supports 
>      the init/main model
>   2. Look for main(String args[] ), and call it just like Java does.
>   3. If a stop() or reload() methods are found, use them to signal
>      the stop/reload events. If not - the shutdown hook will do the
>      job. 
>   4. If a signal() method is found, it is used to deliver unix signals.
>      ( but the application can use JNI and other mechanisms for that if 
>        it chooses to )
> A component that chooses to control the UID itself using native (
> which is a valid model IMO - most unix servers do that, and jk supports
> that ) - then deamon will be able to launch it ( from unix or windows )
> without any problem.
> If a component wants the uid changed by daemon - it'll implement the
> preMain interface and bind on the port/open files/etc there.
> Controlling start/stop of components is a separate issue - it can
> be done with JMX or any other mechanism that the program wants to use.
> Deamon will be useable with any program that implements main(), 
> and require no explicit dependencies ( i.e. other launchers could
> be used, without having to have deamon.jar around if we don't use it ).
> The point is to keep commons-daemon focussed on starting a service
> for NT or a unix daemon. Other mechansims can be used ( jk_nt_service,
> java_service, wrapper ), and it shouldn't require a particular 
> design ( i.e. bind everything on init() ).
> How components are managed after startup is orthogonal ( JMX or
> avalon or coyote handlers or introspection or direct calls or anything 
> else ). Daemon should just send the notifications it can if some
> simple pattern is used ( i.e. stop message or any unix signal ).
> In any case, tomcat shouldn't depend directly or require daemon
> ( but I'm ok with bundling it )

Ok. What you propose looks ok, and it seems it would provide similar 
functionality. Other than the controller, the interface is so trivial it 
is indeed not needed. And DaemonLoader should be enhanced to be more 
flexible with what it can control.

Do you have time to implement what you propose ?


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

View raw message