Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
In fact it should be daemon... But I want to see what JSR-096 comes up with before switching... I'm on the expert group, and we're evaluating several different approaches, including this one... Pier OK. A dot from me. Incze
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
So, now I'm stuck. Which one do you think is better (lately, I'm more oriented towards the second approach!) Pier The HP Core Services Framework defines the abstract service base class by marker interfaces as Destroyable, Initializable, Reconfigurable, Startable, Stoppable Avalon has more marker interface groups (activity, context, configuration, parameters) enabling you to make finer distictions (alltough it's a question whether you can utilize it or not). So, even your second approach seems to me a very minimalistic one. incze
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
public interface Service {
public void init(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
public void destroy() throws Exception;
}
Allways pressing the send button (actually, the 'y' letter in mutt)
too early. I've listed Avalon and CSF just because of the marker
interfaces. If you define a Service interface straight, you
hijack the the concept of service this way, which can be unsatisfactory
for other software componewnts that smell to be service, too.
If you use marker interfaces, then you can implement exactly that
functionality for your services what you want. In the HP CSF they
define the AbstractService abstract class to implement the minimal
service functionality, and real services may extend that.
incze
cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
pier01/07/30 16:23:55 Added: java/org/apache/service Service.java Log: Initial draft of the Service interface. Revision ChangesPath 1.1 jakarta-tomcat-service/java/org/apache/service/Service.java Index: Service.java === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 2001 The Apache Software Foundation.* * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *notice, this list of conditions and the following disclaimer. * * * * 2. Redistributions in binary form must reproduce the above copyright * *notice, this list of conditions and the following disclaimer in the * *documentation and/or other materials provided with the distribution. * * * * 3. The end-user documentation included with the redistribution, if any, * *must include the following acknowlegement: * * * * This product includes software developed by the Apache Software * *Foundation http://www.apache.org/. * * * *Alternately, this acknowlegement may appear in the software itself, if * *and wherever such third-party acknowlegements normally appear. * * * * 4. The names The Jakarta Project, and Apache Software Foundation * *must not be used to endorse or promote products derived from this * *software without prior written permission. For written permission, * *please contact [EMAIL PROTECTED].* * * * 5. Products derived from this software may not be called Apache nor may * *Apache appear in their names without prior written permission of the * *Apache Software Foundation.* * * * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES * * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * * THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY * * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * * POSSIBILITY OF SUCH DAMAGE. * * * * = * * * * This software consists of voluntary contributions made by many indivi- * * duals on behalf of the Apache Software Foundation. For more information * * on the Apache Software Foundation, please see http://www.apache.org/. * * * * = */ package org.apache.service; /** * * @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a * @author Copyright copy;
RE: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote:
[...]
public interface Service {
public void load(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
}
I keep going back and forth between two ideas: the first one
is the above
one, where a service is simply tied to the JVM process.
Basically, when the JVM process is created, load(...) then start() are
called, and at shutdown stop() is called.
Another idea would be this one:
public interface Service {
public void init(ServiceContext context) throws Exception;
public void start() throws Exception;
public void stop() throws Exception;
public void destroy() throws Exception;
}
This differs from the first one _not_only_ because a new
method is added,
but also because the lifecycle of a Service is different: when the JVM
process is created init() is called (instead of load, but
it's the same
shit), destroy() is called before the VM process is shut
down, but start()
and stop() simply imply that a Service could be started and
stopped many
times within the life of the JVM process...
So, now I'm stuck. Which one do you think is better (lately, I'm more
oriented towards the second approach!)
Pier
i kind of like the second approach.
i like the idea, for example, of being able to tweak a config file, then
restart a service without having to restart the entire vm.
also, it has nice symmetry with the servlet api :)
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Kevin Seguin at [EMAIL PROTECTED] wrote: i kind of like the second approach. That's what I'm oriented for... i like the idea, for example, of being able to tweak a config file, then restart a service without having to restart the entire vm. Well, that's not _always_ true... For example, if in your config file you change the port from 80 to 800 (both privileged, btw), you will have to restart the VM. start() and stop() are merely a pause and continue, as most of your configurations should be handled in init(), and that gets called only _once_ within your JVM process... also, it has nice symmetry with the servlet api :) Yeah, I like the symmetry too :) Pier
cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
pier01/07/30 18:26:39
Modified:java/org/apache/service Service.java
Log:
Final layout of the Service interface. Craig and Kevin convinced me that
this is the best way to go:
- init() and destroy() will be tied to the lifecycle of the VM process in
the underlying operating system
- start() and stop() will allow starting and stopping of the Service several
times during the VM process life.
Revision ChangesPath
1.2 +36 -2 jakarta-tomcat-service/java/org/apache/service/Service.java
Index: Service.java
===
RCS file: /home/cvs/jakarta-tomcat-service/java/org/apache/service/Service.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Service.java 2001/07/30 23:23:55 1.1
+++ Service.java 2001/07/31 01:26:39 1.2
@@ -61,14 +61,43 @@
* @author a href=mailto:[EMAIL PROTECTED];Pier Fumagalli/a
* @author Copyright copy; 2000-2001 a href=http://www.apache.org/;The
* Apache Software Foundation/a. All rights reserved.
- * @version 1.0 i(CVS $Revision: 1.1 $)/i
+ * @version 1.0 i(CVS $Revision: 1.2 $)/i
*/
public interface Service {
/**
+ * Initialize this codeService/code instance.
+ * p
+ * This method gets called once the JVM process is created and the
+ * codeService/code instance is created thru its empty public
+ * constructor.
+ * /p
+ * p
+ * Under certain operating systems (typically Unix based operating
+ * systems) and if the native invocation framework is configured to do
+ * so, this method might be called with isuper-user/i privileges.
+ * /p
+ * p
+ * For example, it might be wise to create codeServerSocket/code
+ * instances within the scope of this method, and perform all operations
+ * requiring isuper-user/i privileges in the underlying operating
+ * system.
+ * /p
+ * p
+ * Apart from set up and allocation of native resources, this method
+ * must not start the actual operation of the codeService/code (such
+ * as starting threads calling the codeServerSocket.accept()/code
+ * method) as this would impose some serious security hazards. The
+ * start of operation must be performed in the codestart()/code
+ * method.
+ * /p
*
+ * @param context The codeServiceContext/code instance associated with
+ *service codeService/code instance.
+ * @exception Exception Any exception preventing a successful
+ * initialization.
*/
-public void load(ServiceContext context)
+public void init(ServiceContext context)
throws Exception;
/**
@@ -82,5 +111,10 @@
*/
public void stop()
throws Exception;
+
+/**
+ *
+ */
+public void destroy();
}
