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