You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Christopher M. Cardona" <ch...@gmail.com> on 2006/10/06 09:18:09 UTC

Re: JMX Viewer

See inline comments...

anita kulshreshtha wrote:
> Comments inline..
>
> --- "Christopher M. Cardona" <ch...@gmail.com> wrote:
>
>
>   
>>> 1. Is it possible to display 'Geronimo MBeans' (console.doc) sorted
>>> according to the configurations they belong to?
>>>       
> <snip>............... 
>   
>> One thing we can do is
>> to 
>> add a list of ServiceModules and clicking each node will list its
>> MBeans 
>> which is almost close to what you want. 
>>     
>
>    This would be nice to have.
>
>   
OK. I already created a JIRA for this - 
http://issues.apache.org/jira/browse/GERONIMO-2448.
>>> 2. Is it possible to view tomcat MBeans?
>>>   
>>>       
>> Yes. Currently there are two ways to do this the fastest. One option
>> is 
>> to navigate the tree - Geronimo MBeans > GBean. Another option is to
>> do 
>> an MBean search using a pattern like: “geronimo:j2eeType=GBean,*”.
>> Both 
>> will give a list of all the GBeans which include the Tomcat MBeans.
>>     
>
>    This only gives only the MBeans that have been exposed via GBeans. A
> typical tomcat MBean has a name attribute like:
> Name: Geronimo:type=Connector, port=8443, address=%2F0.0.0.0
>
>      If you are using kernel.listGBeans to find the MBeans, they will
> not be visible. One must query the MBeanserver to find these. Earlier
> listGBeans used to return all the MBeans. Let's wait for other
> suggestions about how to do this.. 
>  
>   
Yes my implementation is using Kernel.listGBeans() so I'm not doing a 
direct query to the MBeanServer. There might be a reason why other 
Tomcat MBeans are not being returned. I agree that we should wait for 
suggestions to retrieve it.
>>> 3. I like the jconsole's view of the attributes (jconsole2.doc).
>>>       
>> The
>>     
>>> attributes are color coded. Jconsole even allows modification of
>>>       
>> these
>>     
>>> attributes. I am not sure if we want to allow that. Please compare
>>>       
>> this
>>     
>>> with console2.doc
>>>   
>>>       
>> I think this is doable. We can set the Attribute value’s color
>> depending 
>> on its property (readonly, writable, unavailable). Right now
>> modifying 
>> the attribute values is supported but with limitation. We can only
>> set 
>> the values for attributes with primitive data types and some commonly
>>
>> used classes that can be constructed with a String class. A button 
>> should display under the Setter column if an attribute is writable.
>> Not 
>> sure if we want to allow this but my initial implementation allows
>> it.
>>     
>
>    I get an 'error:invalid reply from the server' while setting the
> value using the setter button. After this the JMX viewer stopped
> working. It kept returning same error for all the clicks.
>
>   

I'm not seeing this in my machine. Can you please file a jira for this 
and include some steps on how to replicate the error?

>   
>>>    The following are minor things that should be easy to fix - 
>>> 1. The deploymentDescriptor attribute of the WebModule (see
>>> framework.war) is not right.
>>>   
>>>       
>> Can you give more details? What is not right?
>>     
>
>    The value of DD is not right. (See DD.jpg). To create this search
> for j2eeType=WebModule and click on remote-deploy-tomcat. The DD was
> not listed as an attribute in the normal display of J2EEMBeans -->
> WebModule.
>    All the attributes of TomcatWebConnector are not listed.
>
>   

I'm not seeing the exact problem you are seeing but I was able to 
replicate the problem of not displaying all the attributes of a web 
module. I created a jira for this - 
http://issues.apache.org/jira/browse/GERONIMO-2471

>>> 2. In 'J2EE MBeans' --> attribute display the Getter and Setter
>>>       
>> columns
>>     
>>> are redundant. And we should color code the value of
>>> readable/writable/manageable attributes (jconsole2.doc). I do not
>>>       
>> know
>>     
>>> how easy this will be.
>>>   
>>>       
>> Can you explain more why you think it’s redundant?
>>     
>
>     A readable attribute X implies it has a getter. If the attribute
> type is boolean the getter is 'isX' otherwise it is getX. The only
> exceptions to this are the magical attributes like classloader, kernel
> etc. Similarly a writable attribute implies a setter. We should use a
> different color for magical attribute (if possible).
>
>   

IMO this might be automatic for us developers but not for 
non-developers. We can’t expect that all users of the console are 
technical. One reason why these columns are included here is for 
completeness. These are all the information that we can extract from a 
GAttributeInfo class. Another reason is the setter column is used to 
display a button with the setter name as the label for setting writable 
attributes. The getter might be used the same way for getting the latest 
value of an attribute as a future enhancement. Removing these columns 
will disable these features. I’m open to removing these columns if 
others think this is a bad idea.

>>> 3. Jconsole does not display GBeanInfo but JMX Viewer does. The JMX
>>> viewer should display a message 'click here for more info' in the
>>> geronimo.config -->'GBeanInfo' row, and display full information
>>>       
>> only
>>     
>>> when the user clicks on it. Jconsole has similar feature for some
>>> values. The current view (console3.doc) is hard to comprehend.
>>>   
>>>       
>> A couple of things we can do here. One is to totally remove the
>> display 
>> of GBeanInfo attribute which I think is redundant data or if we
>> decide 
>> not to remove it then I can just copy what JConsole is doing which is
>> to 
>> display ‘Unavailable’ for the GBeanInfo value. Your suggestion of 
>> clicking and displaying full information needs more work because of
>> the 
>> way Dojo table widget is designed. What do you think?
>>     
>    
>      We should remove it for now. If you think someone might want to
> add this feature in the future, please open a Jira issue.
>    Once again thanks for your enormous effort.
>
>   
Agreed. Created a jira for this - 
http://issues.apache.org/jira/browse/GERONIMO-2472.

Thanks again for your comments.

Best wishes,
chris

> Thanks
> Anita
>
>   
>>>   
>>>      I hope you find these comments constructive.
>>>
>>> thanks
>>> Anita
>>>   
>>>       
>> This helps a lot. Any feedback I can get is always positive. ;)
>>
>> Best wishes,
>>
>> Chris
>>
>>     
>>> __________________________________________________
>>> 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 
>
> ------------------------------------------------------------------------
>
>