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.
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.
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?
thanks, david jencks
