On Monday, January 12, 2004, at 10:57 PM, Dain Sundstrom wrote:
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.
I have no problem with immutable info classes. I just want some help constructing them in stages, which is easy to do with the mutable info classes. Having the mutable /immutable "versions" of the info classes as unrelated classes is a good idea, if you have both.
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).
Are you saying there should be no inheritance between objects involved in geronimo services? Say the EJB containers?
How 'bout if you start with the web stuff? It has lots of shallow inheritance and is pretty simple otherwise. Maybe with an example I'll see what you are talking about. So far the mutable helper looks like a good idea to me, I'd like to see your alternative approach.
<snip>
everything else I said was basically a suggestion that IDEA refactoring support could be tricked into converting to the new framework with very little work.
david jencks
-dain
