A few thoughts:
- many of the Tomcat MBeans are not and were not supported in AMX (eg
the valve-related ones)
- it's OK to delegate to another MBean, even in V3
- changing the domain name from com.sun.appserv to "tomcat" for tomcat
MBeans would make the distinction clear, and prevent inppropriate
usage from V3
Lloyd
On Mar 21, 2008, at 10:16 PM, Kedar Mhaswade wrote:
> Jan,
>
>> We can't simply not register them without breaking the web container.
>> The monitoring mbeans delegate to these beans, and every http
>> listener populates
>> or clears its request mapper in response to the registration or
>> unregistration,
>> respectively, of these beans.
>> Why should these beans no longer be registered?
>
> I think we have got to make decision here. This delegation thing
> is simply being rather too round-about. We seem to be deviating toward
> having one AMX - MBean API and its implementation that does the
> right thing
> directly. It's too many MBean "layers" otherwise. Thus all config/
> monitoring
> and runtime information should be expose through AMX API and
> implementation.
>
> Somehow, we need to have AMX implementation classes for say servlet
> call into the web-container implementation to get the values, both
> for runtime and monitoring aspects.
>
> Would you or Amy or JFA have time to talk to Lloyd in this regard?
> This does not need to be done for TP-2.
>
> Regards,
> Kedar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc