GeronimoMBeanEndPoint - operation vs. attribute

[gianny DAMOUR <gi...@hotmail.com>]

Hello,


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.

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.

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?

Thanks,
Gianny

_________________________________________________________________
Say “goodbye” to busy signals and slow downloads with a high-speed Internet 
connection! Prices start at less than $1 a day average.  
https://broadband.msn.com (Prices may vary by service area.)

Re: GeronimoMBeanEndPoint - operation vs. attribute

[Dain Sundstrom <da...@coredevelopers.net>]

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
  *************************/