I hadn't really thought about footprint issues, but that's a good point.
Put another way, my concern is:
Can a component's management interface be modified without also
replacing g-mangement?
Best wishes,
Paul
On Nov 8, 2007, at 11:56 AM, Anita Kulshreshtha wrote:
--- Paul McMahan <[EMAIL PROTECTED]> wrote:
While I think that technically Anita is correct this approach
produces some practical challenges.
If all the *StatsImpl classes for all components in the server are
gathered in g-management then how can the *StatsImpl classes be
upgraded, modified, or replaced without also replacing g-
management?
Paul,
We are talking about few classes (e.g. 3 each for tomcat/Jetty)
per
component not few jars. I do not think it is worth having separate
g-management for each assembly. Especially when we still ship all
specs
_jars_ in the smallest assembly.
I hope this answers your concerns..
Thanks
Anita
The g-management module would become a major source of
contention as various components fix and improve their management
interfaces (and we hope they do).
And since g-management is part of
the core framework I think replacing it would require recycling the
server (not verified).
Let's weigh this out against the overhead of maintaining separate
configs for each of the various assembly configurations, which is
certainly no trivial matter.
Best wishes,
Paul
On Nov 8, 2007, at 10:10 AM, Anita Kulshreshtha wrote:
--- "Erik B. Craig" <[EMAIL PROTECTED]> wrote:
say, openEJB or somesuch
would also
reside here rather than within our openEJB package? If so, how
would
this
all play into the pluggable server/framework design?
Since these classes ONLY depend on management classes and not
on
openEJB or somesuch, it does not affect the pluggable
server/framework
design. I do not think we are planning to strip down classes from
g-management to cater to pluggable framework and add classes as we
upgrade to a higher assembly.
Thanks
Anita
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
