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.
Do not confuse assume config; all MBeans are represented.
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.
>
>
> 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.
>
> And that would be fine for the elements in domain.xml we know about
> now. Of course new modules can arrive with quite different
> characteristics and ways of recording information, and we
> (GlassFish) have no hope of documenting them since we cannot predict
> them.
Correct. But there is no ambiguity involved.
>
>
> 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.
>
>
> Another point. I think the proposed path syntax is so close to a
> subset of XPath - while differing from it in key respects - that it
> is worth saying in the document that it is NOT XPath despite the
> resemblance. The key difference I noticed - perhaps there are more
> - is that XPath's selection based on value has the form
OK.
>
>
> /domain/configs/config/[@name="server-config"]
>
>
> as compared to the proposed AMX path
>
> /domain/configs/config/[server-config]
>
> 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).
Actually we resolve against the "name" field of the ObjectName, which
ultimately (for config) is derived from the key value.
>
> I am not advocating making AMX an exact subset of XPath. I am,
> though, mildly concerned that some administrators, who might be some
> of the direct users of the AMX path syntax, might be familiar with
> XPath and therefore be thrown off a bit by the almost-but-not-quite-
> XPath nature of the AMX path syntax.
> 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.
If pathnames are mapped to other entities besides MBeans, then that
subsystem would need to define what the name means. But there is no
intent to select on multiple attributes. That's grossly overcomplex
IMO.
> We'd need to look more carefully for differences than I have so far,
> but I don't think there'd be any ambiguity in the [server-config]
> vs. [@name="server-config"] formats, for example
>
> Just a thought.
>
> - Tim
>
> Lloyd Chambers wrote:
>> Pathnames proposal for V3, intended for use in URLs and admin CLI
>> is now a separate doc:
>>
>> https://glassfish.dev.java.net/nonav/v3/admin/planning/V3Changes/V3_Pathnames.html
>>
>>
>> Lloyd Chambers
>> lloyd.chambers_at_sun.com
>> GlassFish Team
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team