>> The filter works on the MBean's ObjectName.
>> Typing "name" will match any MBeans which has a property with a
"name"
>> key (and a lot of MBeans will match!).
>> The MBean Explorer display only the values of the ObjectName
>> properties (as nodes of its tree). To make it consistent with the UI,
>> a refinement could be to filter only on the ObjectName properties
>> values (and not their keys).
> What confuses me is that I can't see in the ui for all matched items
> someting that includes "name" which is what I would expect when typing
> a filter onto a tree...right ?
The MBean Explorer tree tells only half of the story, it displays the
property values but not the keys.
For example, the MBeans associated to "foo:type=Bar,name=Alice" &
"foo:type=Bar,name=Bob" will be displayed in the tree as
- foo
- Bar
- Alice
- Bob
UI-wise, you can not know from the tree that "Bar" corresponds to the
"type" property and "Alice" to the "name" property.
In practice, it is rarely a problem as long as the ObjectNames are
constructed using JMX best practices[1].
Well, in this example I can see that both Alice and Bob is related to type
Bar.
But there is something else flakey about it. See
http://screencast.com/t/Sdtbv0HA
Sometimes the results is not expanded. Sometime typing the same query
gives different
result (looks like the previous filter affects the new result ?)
I see 2 options there:
#1 - keep the tree as it is and filters only on the visible parts of the
ObjectNames (i.e. the domain & the properties' values)
I think this makes sense.
#2 - display the properties keys in the tree and filter on the full
ObjectName:
- foo
- type=Bar
- name=Alice
- name=Bob
Too verbose...
>> yes, the filter is case sensitive.
> Shouldn't it be case insensitive ?
> Any usecase for it not being ?
I like my search to be case-sensitive by default :)
But, you're right, the filter would be me more user-friendly if case
insensitive.
:)
--
/max