tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pier P. Fumagalli" <>
Subject Re: cvs commit: jakarta-tomcat-service/java/org/apache/service
Date Wed, 01 Aug 2001 23:37:18 GMT
Incze Lajos at 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 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....


View raw message