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: