geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Can we deal generically with container specific jsr77 statistics?
Date Thu, 08 Nov 2007 16:46:28 GMT

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

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

View raw message