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. (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.)
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?
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.
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.
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
/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).
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? 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
>