Thanks Tim, I'll clarify the name part and other issues.
Lloyd
On Mar 24, 2009, at 4:08 PM, Tim Quinn wrote:
> Lloyd Chambers wrote:
>>
>> Tim,
>>
>> Inline.
>>
>> Lloyd
>>
>> On Mar 24, 2009, at 3:33 PM, Tim Quinn wrote:
>>
>>> Hi, Lloyd.
>>>
>>> After reading only briefly through the pathnames and the AMX
>>> documents (I'd like to do read them both more carefully), the
>>> notation seems intuitive and expressive. I know this reflects a
>>> lot of time and energy.
>>>
>>> One thing I didn't see mentioned - and maybe it's there and I
>>> missed it (quite possible) - is that the identifying value usable
>>> in the path expression sometimes maps to a domain.xml element's
>>> "name" attribute value, sometimes to an "id" attribute value, etc.
>>
>> No so.
>>
>> The path part is *always* is a type, and qualified by the name or
>> index if the item is not a singleton within its scope.
> The key point is "name" from where? You clarified below in your
> response that it's from the HK2 @Configured interface definition.
> That needs to be explicit in the AMX document if it's not there
> already. I didn't see it but maybe that's me.
>>
>> Do not confuse assume config; all MBeans are represented.
> I wasn't assuming config only.
>>
>> The type is generally the same as the MBean interface name, but
>> decamelized and dashed eg HttpListener => http-listener. Nothing
>> to do with what's in domain.xml in theory, though in practice it
>> will be the same (HK2 allows overriding the element name instead of
>> basing it on the @Configured).
>>
>> The pathPart defaults as above, except that the MBean can put
>> metadata into its MBeanInfo to override it.
>>
>>
>>
>>> (I also realize that the AMX MBeans might not exactly parallel the
>>> domain.xml and vice versa, but they are closely related in that
>>> often the manageable items do correspond with what domain.xml
>>> describes.)
>>
>> Monitoring is a whole huge tree of its own, probably larger than
>> config.
> Good point. Consider adding a monitoring example in the document to
> help break the "domain.xml"-centric viewpoint people - like me -
> might incorrectly bring to it, especially with all the existing
> examples being domain.xml-based.
>>>
>>> I can see that a particular object at runtime could set its AMX
>>> identifying value to whatever makes sense, but when we document
>>> this to users so there's no ambiguity will we list out the
>>> elements and which attribute corresponds to the identifying value?
>> See above. There is no ambiguity — ever.
> Yeah, I got it now.
>>> Does this impose a documentation requirement on a new module? Are
>>> there conventions possible such that, for example, an attribute
>>> "id" will be treated as the identifying attribute if present,
>>> followed by "name",.. This is probably fairly natural although it
>>> does become a little less intuitive and a little more ambiguous.
>> HK2 already has an annotation to designate the "name" via the key()
>> value. For example:
>>
>> @Attribute(required = true, key=true)
>> public String getId();
>>
>> No ambiguity whatsoever here.
> Yup. By being explicit about the reliance on the HK2 definition for
> the interface on which the path is based you've helped clarify this
> a lot.
>>>
>>> The XPath expression contains the explicit reference to the
>>> attribute name on which to match and quoting of the target value.
>>> The proposed AMX path syntax is certainly briefer and might be
>>> clearer -- as long as users will understand how to link mentally
>>> the value they'd specify in the AMX syntax to whichever is the
>>> identifying attribute in the domain.xml (or whatever naming scheme
>>> applies to the MBeans present in the system).
>> There is no choice here. HK2 @Configured can designate exactly one
>> key() value. Forcing the user to enter that key is completely
>> pointless; we resolve against the key value (for config).
> Agreed now that I understand the link between the path and the HK2
> @Configured definitions.
>>> Obviously it would take more engineering and documentation and
>>> testing effort, but is it worth considering supporting both the
>>> XPath-style syntax and the AMX-style?
>> Nothing to be gained here. By definition the name is always the
>> "name" field of the ObjectName. It would be stupid to have to write
>> "@name" everywhere, because that's the only thing that could be
>> entered.
> Please note that I did not suggest "having to write @name
> everywhere." I suggested we think about supporting both in case some
> users were comfortable with true XPath notation. It may make a lot
> less sense in light of your clarification of the corresponding to
> the "name" of the HK2 @Configured interface.
>
>
> - Tim
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team