Re: Changes to GBeanInfo classes
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
Changes to GBeanInfo classes
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
Re: Changes to GBeanInfo classes
+1 I think there is some dynamic attribute builder code in the connector module builder that may need enhancement david jencks 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
Re: Changes to GBeanInfo classes
On Nov 29, 2004, at 6:00 PM, David Jencks wrote: +1 I think there is some dynamic attribute builder code in the connector module builder that may need enhancement That was one of the first things I checked, and it looks totally clean. -dain
