On Nov 8, 2007, at 7: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.
I agree with you that it is possible to include the Jetty/Tomcat
Stats classes in g-management without pulling in any jetty or tomcat
classes, and similarly all the named geronimo specific stats classes
don't require classes from the components they are for. Similarly I
think its pretty clear my proposal will work and clients can get the
StatsImpl objects and deal with them by finding out what they support.
I'm wondering if it is a good idea to expose classes that turn the
set of Statistics exposed by some particular geronimo component into
a type, or if it is a better idea for clients to use the generic
interface. IIRC when we introduced these classes they seemed like a
good idea but I'm wondering if they have any real use. AFAICT the
classes names w/jetty/tomcat aren't used anywhere outside the jetty/
tomcat modules which makes me think that we should consider removing
all of the non-generic types from g-management, starting with the
Tomcat ones and continuing as time allows.
So to me this is pretty much a philosophical question. I'm leaning
towards only exposing generic classes. What do others think? Why is
it a good idea to have the non-generic classes?
thanks
david jencks
Thanks
Anita
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
