yet again, I reply to my own post.
I can now only see one sensible interpretation for the name field in the OpInfo descriptor and the setMethod/getMethod fields in the AttrInfo descriptor.
OpInfo.Descriptor.name == Method(in target).getName()
AttrInfo.Descriptor.[get|set]Method == OpInfo.getName()
Assuming that MMBs have been spec'd to allow multiple target objects, that's the only interpretation that supports them. Otherwise you open yourself up to name collisions where two different target objects have a getStatus() method and you want to expose one of those methods as a Status attribute.
Still, I could be missing the point...
name is a link between the descriptor and info objects.
the descriptor associated with an operation info must have its name set to the name of the operation info
same for the values of the setMethod and getMethod, they're names of the operations (which is the same in both the info and its associated descriptor).
found the bit in the spec and I agree.
I presume rules for binding an attribute to an op with a role of "setter" or "getter" is the same as for StdMBeans.
I.e. getter has zero length arg list and returns non-void,
setter returns void and has arg list.length == 1, and setter and getter must both refer to the same type.
I'm assuming another restriction when binding an Attribute to an operation - that the type for the operation return value and arg list is identical to the type for the attribute. I.e. I won't be doing any isAssignableFrom() checks.
> I.e. getter has zero length arg list and returns
> setter returns void and has arg list.length == 1, and
> setter and getter must both refer to the same type.
yes, that's the only way it would seem to work. Although it's something that they really should add to the spec and say explicitly.
> I'm assuming another restriction when binding an
> Attribute to an operation - that the type for the
> operation return value and arg list is identical to
> the type for the attribute. I.e. I won't be doing
> any isAssignableFrom() checks.