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? 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
