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