You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/11/07 23:42:07 UTC
Can we deal generically with container specific jsr77 statistics?
There's been some discussion on https://issues.apache.org/jira/browse/
GERONIMO-3586 and https://issues.apache.org/jira/browse/GERONIMO-3587
about how to deal with the jetty and tomcat jsr77 statistics. It
might be good to try to have such discussions on the dev list...
I talked with Viet about this on IRC for a while and have an idea to
suggest that might keep the container specific code in the containers
and allow management code to avoid needing any container specific
classes.
According to my IDEA project setup and Viet, the container specific
interfaces and implementations are only used inside the jetty and
tomcat containers to make it easier for the container to update the
statistics. They are not used in the monitoring plugin. IIUC the
problems start when you try to send e.g. a JettyWebConnectorStatsImpl
over the wire to a monitoring app, and the object can't be deserialized.
I suggest we have in geronimo-management a StatsImpl class similar to
the existing one but taking the name-statistic map in its constructor
and being immutable.
Then the jetty/tomcat specific stats classes won't implement Stats at
all but just the container specific method. Instead of extending
StatsImpl they will delegate to an instance they create in their
constructor.
The MEJB can return the delegate StatsImpl objects, thus avoiding any
need for any container specific classes, and the container specific
adapters can be in with the containers.
Comments?
thanks
david jencks
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Viet Nguyen <vh...@gmail.com>.
> I suggest we have in geronimo-management a StatsImpl class similar to
> the existing one but taking the name-statistic map in its constructor
> and being immutable.
>
> Then the jetty/tomcat specific stats classes won't implement Stats at
> all but just the container specific method. Instead of extending
> StatsImpl they will delegate to an instance they create in their
> constructor.
>
> The MEJB can return the delegate StatsImpl objects, thus avoiding any
> need for any container specific classes, and the container specific
> adapters can be in with the containers.
>
I noticed that in the JSR 77 spec, the generic classes such as
EJBModuleStats extends Stats. Meaning the EJBModuleStatsImpl will
extend StatsImpl, the way things are with the Jetty/Tomcat specific
stats right now. So if we took the specific Jetty/Tomcat stats code
(something that is not defined by JSR-77) and used the technique you
suggested, David, do you think that will be a tolerable inconsistency?
I have tested your idea and everything works fine. If there are no
objections I can put a create a new jira along with the patch.
-Viet
> Comments?
>
> thanks
> david jencks
Re: Can we deal generically with container specific jsr77 statistics?
Posted by David Jencks <da...@yahoo.com>.
On Nov 19, 2007, at 7:33 AM, Viet Nguyen wrote:
> I believe Anita is correct on this one. The specs define that we need
> the getXYZ() methods for each statistics named XYZ. At this point, I
> think we need to move forward with a decision a) put everything in
> g-management or b) split jetty/tomcat stats apart.
>
> As for me, I say let's just go with option A. In order for the
> monitoring plugin to work on both assemblies this issue needs to be
> resolved. If we plan on releasing the monitoring plugin with 2.1,
> we'll need to have time to test it on both assemblies.
After reading Anita's explanation I agree A is the way to go. Sorry
for the apachecon delay in responding.
thanks
david jencks
>
> Thanks,
> Viet
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Viet Nguyen <vh...@gmail.com>.
I believe Anita is correct on this one. The specs define that we need
the getXYZ() methods for each statistics named XYZ. At this point, I
think we need to move forward with a decision a) put everything in
g-management or b) split jetty/tomcat stats apart.
As for me, I say let's just go with option A. In order for the
monitoring plugin to work on both assemblies this issue needs to be
resolved. If we plan on releasing the monitoring plugin with 2.1,
we'll need to have time to test it on both assemblies.
Thanks,
Viet
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
IIUC, you are saying that the container specific StatsImpl will
have the extended map to define extra statistics, but getStats() will
return generic StatsImpl.
JSR77.6.10.1.1 requires that for every statisitc named XYZ, there
must be a method named getXYZ to get the value of the statistics. In
other words adding statistic to the map is not enough. More inline...
--- David Jencks <da...@yahoo.com> wrote:
>
> 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.
If we tell the client that a component is a statisticsProvider, than
it must provide getStats() in accordance with JSR77.6.10.1.1.
>
> 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
That would certainly make using any other tool a bit harder than it
needs to be. One must figure out where all the StatsImpl that could
possibly be supported by geronimo are defined, and put all the jars on
the classpath.
>
> 3. Specific interfaces in g-management, and we expect clients to use
>
> the specific interfaces.
I am all for this :). I am looking forward to a convincing argument
for not choosing this.
Thanks
Anita
>
> 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
> >
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
Posted by David Jencks <da...@yahoo.com>.
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" <gi...@gmail.com> 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
>
Re: Can we deal generically with container specific jsr77 statistics?
Posted by David Jencks <da...@yahoo.com>.
On Nov 8, 2007, at 7:10 AM, Anita Kulshreshtha wrote:
>
> --- "Erik B. Craig" <gi...@gmail.com> 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
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Paul McMahan <pa...@gmail.com>.
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 <pa...@gmail.com> 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" <gi...@gmail.com> 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
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Paul McMahan <pa...@gmail.com> 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" <gi...@gmail.com> 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
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Paul McMahan <pa...@gmail.com>.
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" <gi...@gmail.com> 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
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- "Erik B. Craig" <gi...@gmail.com> 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
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
We do not control what openEJB or somesuch ship with. We need to
make all StatsImpl available via g-management.
Thanks
Anita
--- "Erik B. Craig" <gi...@gmail.com> wrote:
> At the risk of getting caught in the crossfire here...
>
> So, lets say the classes for jetty or tomcat that extend those in
> o/a/g/management/geronimo/stats reside within same package... are we
> then
> saying that classes extending those for, 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?
>
>
> -Erik
>
> On Nov 8, 2007 9:31 AM, Joe Bohn <jo...@earthlink.net> wrote:
>
> >
> >
> > Anita Kulshreshtha wrote:
> > > David,
> > > Please see
> > >
> https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > > To summarize, the question is whether Tomcat*Stats (and
> > > Tomcat*StatsImpl) is a management interface or a tomcat
> interface. To
> > > me, if it imports only management classes, it is a management
> interface
> > > and its implementation which also imports ONLY management classes
> > > belongs in g-management.
> > > Given that all management interfaces and their 33
> implementations
> > > are in g-management,
> >
> > Just to clarify the structure and the history:
> >
> > The standard Stats from the the JSR77 spec are in
> o/a/g/management/stats
> >
> > The "generic" Geronimo Stats which are extensions to the spec are
> in
> > o/a/g/management/geronimo/stats
> >
> > Until recently, the o/a/g/management/geronimo/stats package only
> > included generic stats classes (meaning they were not supposed to
> be
> > specific to the implementation of the component such as Jetty or
> > Tomcat). Jetty specific classes which extended these generic
> classes
> > were in o/a/g/jetty and the intention was that tomcat specific
> classes
> > would be included in tomcat.
> >
> > Joe
> >
> >
>
>
> --
> Erik B. Craig
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
Posted by "Erik B. Craig" <gi...@gmail.com>.
At the risk of getting caught in the crossfire here...
So, lets say the classes for jetty or tomcat that extend those in
o/a/g/management/geronimo/stats reside within same package... are we then
saying that classes extending those for, 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?
-Erik
On Nov 8, 2007 9:31 AM, Joe Bohn <jo...@earthlink.net> wrote:
>
>
> Anita Kulshreshtha wrote:
> > David,
> > Please see
> > https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > To summarize, the question is whether Tomcat*Stats (and
> > Tomcat*StatsImpl) is a management interface or a tomcat interface. To
> > me, if it imports only management classes, it is a management interface
> > and its implementation which also imports ONLY management classes
> > belongs in g-management.
> > Given that all management interfaces and their 33 implementations
> > are in g-management,
>
> Just to clarify the structure and the history:
>
> The standard Stats from the the JSR77 spec are in o/a/g/management/stats
>
> The "generic" Geronimo Stats which are extensions to the spec are in
> o/a/g/management/geronimo/stats
>
> Until recently, the o/a/g/management/geronimo/stats package only
> included generic stats classes (meaning they were not supposed to be
> specific to the implementation of the component such as Jetty or
> Tomcat). Jetty specific classes which extended these generic classes
> were in o/a/g/jetty and the intention was that tomcat specific classes
> would be included in tomcat.
>
> Joe
>
>
--
Erik B. Craig
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Joe Bohn <jo...@earthlink.net> wrote:
>
>
> Anita Kulshreshtha wrote:
> > David,
> > Please see
> > https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> > To summarize, the question is whether Tomcat*Stats (and
> > Tomcat*StatsImpl) is a management interface or a tomcat interface.
> To
> > me, if it imports only management classes, it is a management
> interface
> > and its implementation which also imports ONLY management classes
> > belongs in g-management.
> > Given that all management interfaces and their 33
> implementations
> > are in g-management,
I stand corrected, 30 implementations.
Thanks
Anita
>
> Just to clarify the structure and the history:
>
> The standard Stats from the the JSR77 spec are in
> o/a/g/management/stats
>
> The "generic" Geronimo Stats which are extensions to the spec are in
> o/a/g/management/geronimo/stats
>
> Until recently, the o/a/g/management/geronimo/stats package only
> included generic stats classes (meaning they were not supposed to be
> specific to the implementation of the component such as Jetty or
> Tomcat). Jetty specific classes which extended these generic classes
>
> were in o/a/g/jetty and the intention was that tomcat specific
> classes
> would be included in tomcat.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Joe Bohn <jo...@earthlink.net>.
Anita Kulshreshtha wrote:
> David,
> Please see
> https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
> To summarize, the question is whether Tomcat*Stats (and
> Tomcat*StatsImpl) is a management interface or a tomcat interface. To
> me, if it imports only management classes, it is a management interface
> and its implementation which also imports ONLY management classes
> belongs in g-management.
> Given that all management interfaces and their 33 implementations
> are in g-management,
Just to clarify the structure and the history:
The standard Stats from the the JSR77 spec are in o/a/g/management/stats
The "generic" Geronimo Stats which are extensions to the spec are in
o/a/g/management/geronimo/stats
Until recently, the o/a/g/management/geronimo/stats package only
included generic stats classes (meaning they were not supposed to be
specific to the implementation of the component such as Jetty or
Tomcat). Jetty specific classes which extended these generic classes
were in o/a/g/jetty and the intention was that tomcat specific classes
would be included in tomcat.
Joe
Re: Can we deal generically with container specific jsr77 statistics?
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
David,
Please see
https://issues.apache.org/jira/browse/GERONIMO-3586#action_12540957
To summarize, the question is whether Tomcat*Stats (and
Tomcat*StatsImpl) is a management interface or a tomcat interface. To
me, if it imports only management classes, it is a management interface
and its implementation which also imports ONLY management classes
belongs in g-management.
Given that all management interfaces and their 33 implementations
are in g-management, I do not think it is worth the effort maintaining
duplicate classes just for Jetty. I suggest that we move Jetty*Stats
classes to g-management for now. If we start having 2 EJB
implementations, 2 Transaction managers or 2 JMS providers, then we
should implement the alternative suggested by you.
More inline...
--- David Jencks <da...@yahoo.com> wrote:
> There's been some discussion on
> https://issues.apache.org/jira/browse/
> GERONIMO-3586 and https://issues.apache.org/jira/browse/GERONIMO-3587
>
> about how to deal with the jetty and tomcat jsr77 statistics. It
........................... an idea to
>
> suggest that might keep the container specific code in the containers
>
> and allow management code to avoid needing any container specific
> classes.
These implementations DO NOT need any container specific classes.
Until we come across one that needs one, we should put them in
g-management.
>
................. IIUC the
> problems start when you try to send e.g. a JettyWebConnectorStatsImpl
>
> over the wire to a monitoring app, and the object can't be
> deserialized.
Yes, and we must make sure that all StatsImpl (standard and geronimo
specific) are available via g-management to someone who might want to
write a stand alone client, use jconsole or any similar tool to get to
stats.
Thanks
Anita
>
> I suggest we have in geronimo-management a StatsImpl class similar to
>
> the existing one but taking the name-statistic map in its constructor
>
> and being immutable.
>
> Then the jetty/tomcat specific stats classes won't implement Stats at
>
> all but just the container specific method. Instead of extending
> StatsImpl they will delegate to an instance they create in their
> constructor.
>
> The MEJB can return the delegate StatsImpl objects, thus avoiding any
>
> need for any container specific classes, and the container specific
> adapters can be in with the containers.
>
> Comments?
>
> thanks
> david jencks
>
>
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com