name and class fields in MMBOpInfo Descriptor

[squirest]

From the docs for MMBOpInfo descriptor:

name: operation name
class: fully qualified class where method is defined

First off, the class field is pointless because by the time you try to invoke() on a resource you *only* care about methods exposed in the resource.

On to "name".

When trying to resolve a Method object for invoke() do I use the "name" from the descriptor or do I use the the name from the MMBOpInfo?

I would have assumed I would use the one from MMBOpInfo 'cause that's where I have to get the signature from. But then again, the spirit of Descriptors seems to be virtualising everything (operation name "foo" resolves to a method "bar") so maybe I should use the "name" field in the descriptor...

"name" might also be some sort of unique token so that setMethod and getMethod entries in an MMBAttrInfo descriptor can resolve the correct operation...

Choices, choices.

Sigh.
Trev

[squirest]

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...

Trev

[juha]

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

so MBeanOperationInfo.getDescriptor().getFieldValue("name").equals(MBeanOperationInfo.getName())

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).

[squirest]

Ok,

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.

Trev

[juha]

> 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.

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.

ok.

-- Juha