On Jan 12, 2004, at 11:09 PM, David Jencks wrote:
Maybe I haven't looked at enough of the new GMBean code...
It looks to me as if the GBeanInfo class more or less replaces the GeronimoMBeanInfo class, except that it is highly immutable. This will cause a severe conversion problem migrating 95% of the existing GeronimoMBean code, which constructs a GeronimoMBeanInfo object in multiple calls, often through an inheritance hierarchy, each call adding attributes. ops, endpoints, etc to the info object constructed in the most nested call.
I originally started with mutable GBeanInfo objects, but it became much cleaner when we went to immutable info objects. As for conversion we don't have that many existing services, and I plan on paying the price by converting as many as I can myself. Jeremy also had a helper class you could pass around that had mutable sets in them and you could build a final info from the helper, but I thought it was lame (still do). If something like this makes the inheritance code better you could write one, but using inheritance here seems like a bad idea to me (remember I generally hate inheritance).
While it would be possible to change all these getGeronimoMBeanInfo calls to take lots of sets as parameters, this seems too complicated to me.
Instead, how about if we
1. change GeronimoMBeanInfo internals so it is simply a mutable holder for the info.
2. make a constructor for GBeanInfo taking a GeronimoMBeanInfo.
3. adapt the GMBean constructor that looks for a coded GMBeanInfo object so it can also accept a GeronimoMBeanInfo object, constructing the GBeanInfo on the fly.
4. Rename the GeronimoMBeanInfo appropriately and put it in the gbean package. I'd suggest GBeanInfoHolder.
-1 I think if you write a helper for those few classes that need the inheritance hack it will work. We are trying to get rid of all of the old stuff and this will only extend it. While we have both frameworks we can just have a component have both a getGeronimoMBeanInfo method and a getGBeanInfo method.
This might result in a more or less effortless conversion to GMBean... otherwise, how about just a mutable holder object?
BTW why is it GMBean but GBeanInfo?
I suggest you read the code again. This design is very different internally which makes GMBean definitely not an info object. When you write a GBean you should have no knowledge that you are running in jmx (so we/you can port to other containers later), which specifically mean you are not creating mbean info objects. GMBean is the mbean that wraps a GBean exposing the attributes, operations, notifications, and handles all the JSR 77 stuff. We don't have our own MBeanInfo objects anymore as we can easily construct the normal jmx ones.
-dain
