OK, I re-looked at the spec and I guess that makes sense. If I switch to call getAttribute() instead it will work.
According to the spec, however, it does say that "an implementation may also choose to allow the getAttributeName and setAttributeName methods, described in 'Lexical Design Patterns' on page 38, to be invoked as operations."
I'm not sure exactly ... but it seems to read that i should be able to call foo as an attribute, and also getFoo as an operation. ?? Spec vagueness
In these cases, I use:
updateFoo (Foo f)
> According to the spec, however, it does say that "an
> implementation may also choose to allow the
> getAttributeName and setAttributeName methods,
> described in 'Lexical Design Patterns' on page 38, to
> be invoked as operations."
This seems to be a new addition to the JMX 1.1 spec. The earlier 1.0 spec did not allow for this. However, at least Sun's RI had a bug in it where it was possible to invoke the attribute accessor methods as operations. So it seems that rather than fixing their implementation, they decided to "fix" the spec.
We do not allow for this in our current implementation, and haven't so far seen a need to implement this bug either, even though the spec now seems to say it's ok.
> I'm not sure exactly ... but it seems to read that i
> should be able to call foo as an attribute, and also
> getFoo as an operation. ?? Spec vagueness
Notice it says the implementation may choose to allow this. We haven't allowed it.
Hmmm... this doesn't seem to be extremely consistent. Running on 3.0.2, my entity beans have an exposed operation called getCacheSize().
It seems to work just fine.
However, I think cacheSize should be an attribute anyway.
It would seem that it would be fine to first check to see if it was an attribute (is/get/set) and then if an attribute was not found, then try seeing if it maps to an operation and if so, invoke the operation if the signature matched.
It would be very useful, since we have MBean's that map to interfaces that have operations such as getXXX - that can't be expressed as attributes - for example, we have a method sig:
String  getDialogLanguageVersion(String language);
This is impossible in JBossMX to invoke - since an attribute can't have parameters, and since it starts with "get" - I can't invoke it as an operation. Invoking this method fails.
Is there some working around, besides breaking the interface?
getter with args will be invokable as operations
hmmm.. this doesn't seem to work then. I tried getXXXX(args) and it fails. will check into it more.