> Yes, both Apache and tomcat need a mechanism to get status and change
> configuration dynamically.
>
> Session count is a particular case. Adding/removing workers is another
> particular case.
>
> What I'm thinking about is a general solution. The goals:
>
> 1. Extensible/Modular. Maybe you want to get other internal
> informations,
> or change other parameters at run time.
>
> 2. Minimal ( or no ) changes in the core or protocols. Changes are bad
> bacause they add bugs, require releases , etc, and if we do (1) right,
> then no other change is needed.
>
I agree. The less work done to the core, the better. ( and best left to the pros! :)
>
> Well, having Ajp13 or Http listeners is almost the same, you
> don't need
> the HTTP running if you have Ajp13 ( and a Ajp13 client -
> like apache ).
> Regarding login for each query - this is an admin task, so it's not
> performance-critical.
So, in addition to setting up AJP12 in the load balance list, you're saying to set up a AJP13 on each tomcat as well? (to allow [restricted] access to the specific TC) ? Sounds good.
>
> > Whatever the front end is, I'll still need to add
> getSessionCount() methods
> > to the ContextManager, StandardManager, and
> StandardSessionManager. (yes?)
>
> I'm not sure you need to change ContextManager for that - you
> can get the
> list of Contexts, and for each Context you can access the
> StandardManager
> - and get the session count from it. All that can be done (
> IMHO ) from a
> servlet, without any change in the core - the only special thing is
> getting a pointer to the ContextManager.
>
Hmmm, I'll look closer at Context and the StandardManager.
thanks.
>
> > Sorry for the long rant, but I think I'm working on some
> good functionality
> > that others could use as well, and I want to get it right.
>
> +1.
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
