geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: GeronimoMBeanEndPoint - operation vs. attribute
Date Wed, 03 Dec 2003 11:53:10 GMT
Dain Sundstrom 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.
The ability to have endpoints, which connect to standard MBean, could 
potentially be usefull: e.g., when a service is deployed, a "standard" MBean 
is created for the service deployment (I am talking about the 
ServiceDeployment MBean).

By now, if one wants to invoke this ServiceDeployment, then one can either 
invoke it throught the MBeanServer containing this MBean or use a proxy. As 
you have already underlined, the first approach is "bad" as it clearly 
exposes JMX. Conversely, the second one hides it. Unfortunately, this latter 
approach is not possible as ServiceDeployment is not wrapped by a 

>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 
Thanks for that; I think that I understand your point. Now, I do have a 

As a matter of fact, MBeanProxyFactory and GeronimoMBeanEndPointConnection 
do not return the same kind of MethodInterceptor: MBeanProxyFactory 
distinguishes attributes and operations and GeronimoMBeanEndPointConnection 
does not. I assume that this is due to the fact that MBeanProxyFactory 
requires the existence of the MBean to be reflected and 
GeronimoMBeanEndPointConnection does not.

However, I do not really understand why one needs to provide a 
Class/Interface to them: if one decides to lazily create the 
MethodInterceptor - only when the MBean is registered and by retrieving its 
ObjectInstance - then this argument becomes useless. Moreover, it allows to 
support inheritance, which is not currently supported.

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

Here is a big picture of what I am trying to achieve:

A while back, there was a thread on DeploymentPlanner and meta-data 
repositories for deployment units. The idea was to have a meta-data 
repository for each actual deployment. For instance, ServiceDeployment and 
WebDeployment could be considered as "empty" meta-data repositories.

Such a repository could be used to register all the "important" files of a 
deployment as the deployment descriptors, the DeploymentPlanner which has 
mounted the deployment, the JSR88 TargetModuleID et cetera.

I have updated ApplicationDeployer in order to track these repositories: I 
have defined an endpoint associated with the "*:role=DeploymentUnit,*" 

Hopefully, the implementation of ApplicationDeployer should be 
straightforward: one queries the MBeanServer for all the deployment units 
having a TargetModuleID equals to a specific value. One uses the result to 
look-up the endpoint Map (and not the Collection) and one invokes the 
relevant method on the proxy.

As a matter of fact, the previous section has not yet been implemented, 
however this part is done:
I have updated ApplicationDeployer.planDeployment in order check the state 
of deployment units mounted by DeploymentScanners and trigger the execution 
of the relevant goal.
More accurately, if a deployment unit has been injected via a 
DeploymentScanner (this seems to be the old fashion way), then one needs a 
way to assess if it must be redeploy, undeploy et cetera. To do so, one 
invokes a method of this meta-data repository, which derives the relevant 
goal to be achieved, if any.

This mechanism must happen only in the case of deployments mounted via 
scanners. It means that if a scanner injects a URL, which is a deployment 
unit (query of the MBeanServer), then one invokes a method on this 
deployment unit (look-up in the endpoint Map and proxy invocation).

As a matter of fact, one can not declare another endpoint only for 
deployments mounted via scanners without changing the naming convention of 
these deployment units.

I hope that you understand the idea.


Donít worry if your Inbox will max out while you are enjoying the holidays.  
Get MSN Extra Storage!

View raw message