How about just "type" ? I don't want "node". There really is such a thing as a "resource" (which has operations), and then there is the tree structure used to represent the resource tree. In that context "node" is ambiguous. On 3/18/11 6:53 AM, Heiko Braun wrote: -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

On 3/21/11 3:40 AM, Heiko Braun wrote: Doesn't work for JMX. An address needs to be convertible into the key/value pairs that go into the ObjectName. A layer in between the end user and the raw management API, i.e. the CLI or the DomainHttpServer, could detect addresses that aren't entirely composed of pairs and then have some logic to turn the "single" element into an attribute. That requires operation-specific logic in the CLI and DomainHttpServer though. Changing PathAddress to optionally support an "undefined" value for the final element in the address is a possibility. Add overloaded static factory methods that take a boolean to enable this; by default disabled (throwing an exception if found) so all existing operation handlers are safe. This would essentially make this kind of address part of the core API and avoid special handling in the CLI/DomainHttpServer. Doing this last bit makes it possible to support that kind of address. But I'm not convinced it's worth it. There's the JMX issue, where suddenly the way things work is different between interfaces. And then there are problems like the operation description for any operation that supports this kind of address. Operation descriptions say nothing about the address the operation is applied to. They describe parameters and results. But now we've pushed a parameter into the address. -- Brian Stansberry Principal Software Engineer JBoss by Red Hat