You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by pi...@apache.org on 2001/07/31 01:23:55 UTC
cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
pier 01/07/30 16:23:55
Added: java/org/apache/service Service.java
Log:
Initial draft of the Service interface.
Revision Changes Path
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 <ap...@apache.org>. *
* *
* 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:pier.fumagalli@sun.com">Pier Fumagalli</a>
* @author Copyright © 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>
*/
public interface Service {
/**
*
*/
public void load(ServiceContext context)
throws Exception;
/**
*
*/
public void start()
throws Exception;
/**
*
*/
public void stop()
throws Exception;
}
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Posted by Incze Lajos <in...@mail.matav.hu>.
> 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
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Posted by Incze Lajos <in...@mail.matav.hu>.
> 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
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Incze Lajos at incze@mail.matav.hu wrote:
>
> As I see, e.g. in HP CSF there is nothing "under" the services - just the
> "embeddor" which is a the very thin special layer interfacing to the
> actual software environment. But I understand that missed the boat your
> service is not that service. (Anyway, naming is a magical thing.)
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
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Posted by Incze Lajos <in...@mail.matav.hu>.
On Thu, Aug 02, 2001 at 12:37:18AM +0100, Pier P. Fumagalli wrote:
> Incze Lajos at incze@mail.matav.hu wrote:
>
> >>> 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.
>
> I believe I know pretty well how Avalon is designed (being one out of three
> of the first authors :)... But, it seems you're missing the scope of this.
Probably that's the case.
>
> A "Service" is not a generic component, cannot be used in the "Avalon" or HP
> CSF way of doing things (now, that could be generically summed up as
> JSR-111, as both the Avalon team and the HP team joined forces to come up
> with something more "standard").
>
> The Service lifecycle represents the lifecycle of the JVM process in which
> an application is running... Let's say that it is something more than just
> the usual "public static void main()"... It down low close to the OS, and to
> the JVM process... Completely different from a framework...
>
As I see, e.g. in HP CSF there is nothing "under" the services - just the
"embeddor" which is a the very thin special layer interfacing to the
actual software environment. But I understand that missed the boat your
service is not that service. (Anyway, naming is a magical thing.)
> gave A LOT of input for designing the underlying invocation code, AKA, the
> Service !)
>
> Take care....
>
> Pier
Trying.
incze
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Service.java
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Incze Lajos at incze@mail.matav.hu wrote:
>>> 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 Lajos at incze@mail.matav.hu wrote:
>
>> 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.
I believe I know pretty well how Avalon is designed (being one out of three
of the first authors :)... But, it seems you're missing the scope of this.
A "Service" is not a generic component, cannot be used in the "Avalon" or HP
CSF way of doing things (now, that could be generically summed up as
JSR-111, as both the Avalon team and the HP team joined forces to come up
with something more "standard").
The Service lifecycle represents the lifecycle of the JVM process in which
an application is running... Let's say that it is something more than just
the usual "public static void main()"... It down low close to the OS, and to
the JVM process... Completely different from a framework...
All this, of course, IMVHO! (and with the Blessing of the Avalon team who
gave A LOT of input for designing the underlying invocation code, AKA, the
Service !)
Take care....
Pier
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Posted by Incze Lajos <in...@mail.matav.hu>.
> > 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/serviceService.java
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
"Pier P. Fumagalli" wrote:
>
> Craig R. McClanahan at craigmcc@apache.org wrote:
>
> > +1 for the second approach. If the logic of your service allows for
> > "restarting" without forcing an unload/reload of the entire JVM, the APIs
> > should accomodate that.
>
> Again, it would not mean "restart", but merely "pause" and "continue", as
> most of the construction should be performed in init(), since that's the one
> with privileged super-user access in unix...
Something like the graceful restart of httpd.
init creates the ServerSocket as root
start stars the clients threads as tomcat user.
stop stops all the clients threads.
destroy closes the ServerSocket. and unload the entire JVM?
>
> Pier
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Service.java
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Craig R. McClanahan at craigmcc@apache.org wrote:
> +1 for the second approach. If the logic of your service allows for
> "restarting" without forcing an unload/reload of the entire JVM, the APIs
> should accomodate that.
Again, it would not mean "restart", but merely "pause" and "continue", as
most of the construction should be performed in init(), since that's the one
with privileged super-user access in unix...
Pier
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Service.java
Posted by "Craig R. McClanahan" <cr...@apache.org>.
+1 for the second approach. If the logic of your service allows for
"restarting" without forcing an unload/reload of the entire JVM, the APIs
should accomodate that.
Craig
On Tue, 31 Jul 2001, Pier P. Fumagalli wrote:
> pier@apache.org at pier@apache.org 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
>
>
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Service.java
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
pier@apache.org at pier@apache.org 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