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:54:08 GMT
From: <costinm@covalent.net>
> On Wed, 14 Aug 2002, Stephen Colebourne wrote:
> > If Daemon has one or more methods that are going to be called, why can
they
> > not be declared in an interface?
>
> Less coupling. Deamon is not the only way to start an application -
> and we're not in the business of setting standards for how an
> application must be started.

Maybe my question comes down to why are we _not_ in the business of setting
standards for how an application is started (using the Daemon component).

> An interface that must be implemented by the application will also
> make it difficult to use other launchers, will make it difficult
> to use other patterns.
>
> There is no Main interface - java only requires you to have a
> main(String[] ) method. Why would daemon be different ? And how
> many interfaces would we have to implement ( one for each
> launcher ? )

I 'get' the argument for the main method. Reflecting that makes sense (its
static, and its defined by Java ).

But for other methods, and interface seems more appropriate. I think my
problem may lie with my lack of understanding of the different use cases for
Daemon.

What I imagine is the user of the Daemon API either using an implementation
supplied by us, or one they write themselves. In both cases, the Daemon
component calls an init() method to indicate that the implementation should
initialize now. I would use an interface to tell the users that this is the
API, here is what happens and when.

However, what I see being described is that some document somewhere will
define that init() will be called by reflection if the method exists.

What makes this API different to every other in Java?

Stephen
(sorry, for the long discussion - you've clearly got something very clear in
your mind that I just can't grasp at present :-)

> Costin
>
>
>
> >
> >  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>
> >
> >
>
>
> --
> 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