You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Pier P. Fumagalli" <pi...@betaversion.org> on 2001/07/31 01:45:46 UTC
Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Service.java
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 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
>
>