Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java

["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

[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

["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

[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