On Nov 8, 2007, at 8:33 AM, David Jencks wrote:
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?
talking with pmcmahon I think there are 3 choices.... let me try to
make them more explicit.
1. Only generic interfaces in g-management, and we pretty much insist
that clients use the generic interfaces only. If they want something
else its up to them to figure out how to find it, and it might not
exist.
2. Only generic interfaces in g-management, specific interfaces in
the component modules (such as jetty/tomcat) and we expect clients to
use the specific interfaces, thus they will need to import the
component modules to get the interfaces
3. Specific interfaces in g-management, and we expect clients to use
the specific interfaces.
Hope this clarifies what we are talking about.
david jencks
thanks
david jencks
Thanks
Anita
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
