Re: Changes to GBeanInfo classes

[Dain Sundstrom <ds...@gluecode.com>]

Done

-dain

On Nov 29, 2004, at 5:43 PM, Dain Sundstrom wrote:

> Summary:
> I think we need to change the GBeanInfo classes so the constructors 
> require all data be specified.  This means that the GBeanInstance (the 
> implementation class) will not try to "figure things out" such as 
> accessor names.  This change will not break Geronimo, OpenEJB or 
> ActiveMQ, since all of these projects never work directly with the 
> GBeanInfo classes directly.  Instead they always work through the 
> GBeanInfoBuilder class.  This will break code that is building 
> GBeanInfo objects directly (I don't know of any but there could be 
> some out there).
>
> Problems:
> The lack of information in the GBeanInfo classes is leading to overly 
> complex code.  The GBeanInfo classes were originally designed to make 
> it easy for programers to create the info objects by hand (in static 
> code blocks).  The classes were designed to take the minimum amount of 
> information necessary to create a GBeanMBean.  Information such as an 
> accessor name could be left unspecified, and the GBeanMBean would 
> guess the accessor name based on JavaBean naming conventions.  This 
> guessing is itself complex, and does not allow for user supplied 
> algorithms for matching.  This lack of information is also carried 
> through the rest of the system.  For example, the kernel has a 
> getGBeanInfo method to retrieve the GBean info for any registered 
> GBean.  The problem is the GBeanInfo is not fully specified, which 
> make it difficult to write things like a kernel based console and the 
> MEJB (We currently have a pretty ugly hack that makes some of this 
> possible).
>
> Solution:
> Change the GBeanInfo classes to require full specification and move 
> the "figure things out" code from the GBeanInstance to the 
> GBeanInfoBuilder.
>
> Impact:
> This direct creation of GBeanInfo objects has been discarded over time 
> and has been replaced with the GBeanInfoBuilder class.  There are very 
> few classes that construct a GBeanInfo or deal with one directly, and 
> most of those are internal to the Kernel.  After checking, Geronimo, 
> ActiveMQ, and OpenEJB, I only found one use of a GAttributeInfo 
> constructor in ActiveMQ, which can trivially be converted to the 
> equivalent GBeanInfoBuilder method.  Quoting from above, "this change 
> will not break Geronimo, OpenEJB or ActiveMQ... This will break code 
> that is building GBeanInfo objects directly (I don't know of any but 
> there could be some out there)."
>
> Benefits:
> GBean implementation becomes a lot less complex.
> Enables the ability to write more complex GBeanInfoBuilders.
> Validation of GBeanInfo is much easier, and happens at GBeanInfo 
> creation time instead of when we attempt to instantiate a 
> GBeanInstance.
> GBean browsers such as MEJB and consoles are much easier to write.
>
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26