geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Date Tue, 30 Dec 2003 21:40:05 GMT
I've converted the web, remoting, and clustering modules to geronimo 
mbeans, as well as a few miscellaneous mbeans.  These appear to be the 
last uses of the original dependency management framework so I removed 
AbstractManagedObject, AbstractManagedContainer, and 

The original dependency service is still referred to by the 
StandardMBean deployment task.  IMNSHO this can best be removed by 
deploying StandardMBeans as geronimo mbeans.  This requires:
-writing something like GeronimoMBeanInfo.addOperationsDeclaredIn to 
look at all interfaces in the xxxMBean inheritance chain and also use 
naming conventions to identify attributes
-interpreting the dependency management stuff for plain mbeans as 
geronimo mbean endpoints.  Since this last feature is not currently 
used AFAIK, the syntax is presumably not fixed in stone.

As a side note, it would be a very nice feature to be able to override 
the endpoint object name pattern supplied in GeronimoMBeanInfo in the 
*-service.xml file instance deployment descriptor.

I've also added a feature to geronimo mbean endpoints.  You now have a 
choice for collection valued endpoints.  You can use the original 
system where you supply a collection valued attribute that is set once 
and modified behind the scenes without notifications, or you can supply 
a GeronimoMBeanEndpointListener object that is notified when an 
endpoint is added or removed from the collection.  I also fixed a 
serious bug in the endpoint management in which GeronimoMBeans were 
being added before they were initialized or useable, let alone started.

Let me know if this has caused problems.

david jencks

On Sunday, December 28, 2003, at 12:50 PM, David Jencks wrote:

> I've converted the security module to GeronimoMBeans.
> I've changed the deployment pattern for EJBModuleConfiguration and 
> WebModuleConfiguration so that the ejb and web deployment planners are 
> expected to deploy these mbeans in a configured state.  Previously it 
> was possible for unconfigured ModuleConfigurations to be generated by 
> lookups on SecuriityService.
> If this change is inconsistent with the JACC spec, please let me know.
> thanks
> david jencks
> On Thursday, December 25, 2003, at 10:03 PM, David Jencks wrote:
>> There are still at least two generations of component code in current 
>> geronimo cvs: the original(?) version requiring fairly explicit 
>> container/containee management and the much simpler and more 
>> automated GeronimoMBean version.  I would like to get this cleaned up 
>> in the next few days.  If the original authors (or someone else) 
>> wants to do this, please speak up, otherwise I will start on it soon.
>> I think it would be better if more people than Dain and I become 
>> familiar with the GeronimoMBean code, so I encourage others to work 
>> on this.
>> The areas I am particularly aware of are:
>> Security framework.  I see that some of the container/containee 
>> management is based on the class of the containee.  This could be 
>> converted to rely on object name patterns to fit in the current 
>> GeronimoMBean structure or perhaps the GeronimoMBean could be 
>> extended to deal with endpoints filtered by class rather than object 
>> name.  In the absence of better understanding I'd move to object name 
>> patterns.  Also, I believe that the thread-based mbean server lookup 
>> in GeronimoLoginConfiguration is misguided and unnecessary.  I think 
>> we can assume that there will be only one mbean server per vm used 
>> for geronimo management.  Other mbean servers in a vm might be used 
>> for other purposes, but I see no need for more than one "Geronimo" 
>> mbean server per vm.  If anyone disagrees, please supply a convincing 
>> use case. Alan, sorry I didn't speak up about this when you 
>> originally asked.
>> Web framework.  Along with converting to use GeronimoMBeans, the 
>> functionality of the web deployer should be separated from the web 
>> container to match the architecture of the other deployer/container 
>> frameworks.
>> There may be other places needing similar work, these are the ones I 
>> have encountered recently.
>> Thanks
>> david jencks

View raw message