tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Incze Lajos <in...@mail.matav.hu>
Subject Re: cvs commit: jakarta-tomcat-service/java/org/apache/service Service.java
Date Thu, 02 Aug 2001 14:01:29 GMT
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

Mime
View raw message