commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [VOTE] [daemon] Moving to commons proper
Date Wed, 14 Aug 2002 22:16:16 GMT
From: "Nicola Ken Barozzi" <nicolaken@apache.org>
> I think that apart from the discussion going on about interfaces, the
> fact that Daemon would use introspection instead of an interface would
> be a *feature*, not a hack to keep Costin or me happy.

In what way? I feel that I must be really dense.

If Daemon has one or more methods that are going to be called, why can they
not be declared in an interface?

 Stephen

> costinm@covalent.net 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 )
> >
> >
> >>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)
> >
> >
> > 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 )
>
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message