On Tuesday, December 2, 2003, at 07:43 AM, gianny DAMOUR wrote:
GeronimoMBeanEndPoint allow to invoke endpoints only via JMX operations: InvokeMBean instances abstracting the connections are always methods.
I do have the feeling that it was an intentional decision.
It was. The idea was that an endpoint would only let you connect to another GeronimoMbean. GeronimoMBeans automatically expose attributes as operations (unless there is a registered operation in the way). I'm not sure that we need endpoints to connect to other mbean types, but we can add it if someone needs it.
If my assumption is true, then I would like to change the implementation in order to distinguish operations and attributes. The goal is to try to stick to the "lexical design patterns" of the JMX specifications. As a matter of fact, such an update means that MBeanInfo returned by endpoints must also be compliant.
I don't think it will work to just follow the lexical design patterns of JMX. Those patterns only apply to standard MBeans and dynamic MBeans are pretty much allowed to do anything. I suggest you take a look at org.apache.geronimo.kernel.jmx.MBeanProxyFactory as it uses the MBean meta data to determine if the method should be called using an attribute or operation.
Aside this update, I also would like to change the formal parameters of endpoints having more than one target. By now, such endpoints are declared/defined like this:
public void setMyEndPoint(Collection aCollectionOfProxy);
I would like to declare them like this: public void setMyEndPoint(Map aMapOfProxy);
where aMapOfProxy is an ObjectName to proxy map.
This latter approach allows to perform "informed" invocations (in other words based on the ObjectName) on the endpoints.
Any concern?
I don't like this as it adds in more dependencies on JMX, and I think we should strive to have no dependencies (eventually). If someone wants differentiate the MBeans in an endpoint I think they should simply declare another endpoint which maps to the interesting subset.
-dain
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
