Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 27373 invoked from network); 14 Aug 2002 22:28:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Aug 2002 22:28:39 -0000 Received: (qmail 2766 invoked by uid 97); 14 Aug 2002 22:29:06 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2750 invoked by uid 97); 14 Aug 2002 22:29:05 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 2738 invoked by uid 98); 14 Aug 2002 22:29:05 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Wed, 14 Aug 2002 15:24:59 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List cc: nicolaken@apache.org Subject: Re: [VOTE] [daemon] Moving to commons proper In-Reply-To: <00e301c243e0$374e2a40$711c29d9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 14 Aug 2002, Stephen Colebourne wrote: > From: "Nicola Ken Barozzi" > > 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? 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. 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 ? ) 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: > > > For additional commands, e-mail: > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: