You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <ds...@gluecode.com> on 2004/11/25 23:04:38 UTC
GBean now JMX free
I just committed the change to the GBean code that removes the
dependency on JMX. The code now only uses the Kernel and ObjectName.
Of course the kernel is still implemented with JMX, but the GBean code
is not aware of this.
To accomplish this, I moved most of the code in the
org.apache.geronimo.gbean.jmx package to
org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but it
contains almost no logic. All of the code that was in the GBeanMBean
has been moved to GBeanInstance. The GBeanMBean is not depredated, and
you should use GBeanData instead and let the kernel create the
GBeanMBean for you using the loadGBean(gbeanData, classLoader).
Additionally, you should not use GBeanInstance directly. It is
considered part of the internals of the GBean architecture, and is
marked as deprecated.
I also did some of the conversion from JMX exception to Geronimo
specific exception. I only did this for setAttribute, getAttribute and
invoke on the kernel. I would finish this, but I'm already getting in
trouble for working on a holiday :) If someone decides to take this
up, I suggest we think about adding some properties to the exception
classes such as object name, attribute name, and method signature.
In the process of this, I've added two new kernel services,
ProxyManager and LifecycleMonitor. I have marked these both as
depreciated, so we can review the interfaces. We need the basic
functionality to for GBeans, but the interfaces and implementation can
change. Once we are all happy with the services, we can removed the
deprecated tag.
BTW, before I forget the rule with ProxyManager, is if you create a
Proxy you *must* destroy it. Otherwise, we will get a memory leak. I
have some ideas on how to reduce the leaks, but it is good practice to
destroy the proxy as soon as you are done with it.
Happy holidays everyone,
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
Re: GBean now JMX free
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> In a word, yes.
Okay, but in both MX4J 1.1.1 and JDK 1.5.0 documentation, the
argument order for the constructor in question is:
MBeanAttributeInfo(String name, String type, String description,
boolean isReadable, boolean isWriteable, boolean isIs)
In the code I had trouble with, the second argument was "no
description available", whereas after my fix, that's the third argument.
If I've introduced a problem, I'm sorry, but I don't see it?
Aaron
Re: GBean now JMX free
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Nov 25, 2004, at 3:46 PM, Aaron Mulder wrote:
> I looked at the MX4J JavaDoc and the description and type
> arguments to the MBeanAttributeInfo were reversed -- which would
> explain
> why it was complaining about being an is getter without being a boolean
> attribute (though what it made of the attribute class "no description
> available" is beyond me!). It looks like my Javadoc is for MX4J 1.1.1,
> though I'm just using whatever Maven dependency Geronimo uses for JMX
> at
> build time. I tested with Sun JSK 1.5.0 32-bit on SuSE 9.2, and it ran
> fine after the argument swap. Do you think there's some difference
> between MX4J and the JMX RI?
In a word, yes.
-dain
Re: GBean now JMX free
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I looked at the MX4J JavaDoc and the description and type
arguments to the MBeanAttributeInfo were reversed -- which would explain
why it was complaining about being an is getter without being a boolean
attribute (though what it made of the attribute class "no description
available" is beyond me!). It looks like my Javadoc is for MX4J 1.1.1,
though I'm just using whatever Maven dependency Geronimo uses for JMX at
build time. I tested with Sun JSK 1.5.0 32-bit on SuSE 9.2, and it ran
fine after the argument swap. Do you think there's some difference
between MX4J and the JMX RI?
Aaron
On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> That is totally weird. I did the check before I sent the email. Are
> you on Java 5 and using the RI version of JMX?
>
> -dain
>
> On Nov 25, 2004, at 3:06 PM, Aaron Mulder wrote:
>
> > That's because I checked in the fix. :)
> >
> > Aaron
> >
> > On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> >> I just did a clean checkout and rebuild.... worked perfectly for me.
> >>
> >> -dain
> >>
> >> --
> >> Dain Sundstrom
> >> Chief Architect
> >> Gluecode Software
> >> 310.536.8355, ext. 26
> >>
> >> On Nov 25, 2004, at 2:44 PM, Aaron Mulder wrote:
> >>
> >>> This change seems to have broken the security module -- I'm
> >>> getting an error about only boolean attributes can have an "is"
> >>> getter.
> >>> I'm looking into this...
> >>>
> >>> Aaron
> >>>
> >>> On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> >>>> I just committed the change to the GBean code that removes the
> >>>> dependency on JMX. The code now only uses the Kernel and
> >>>> ObjectName.
> >>>> Of course the kernel is still implemented with JMX, but the GBean
> >>>> code
> >>>> is not aware of this.
> >>>>
> >>>> To accomplish this, I moved most of the code in the
> >>>> org.apache.geronimo.gbean.jmx package to
> >>>> org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but
> >>>> it
> >>>> contains almost no logic. All of the code that was in the
> >>>> GBeanMBean
> >>>> has been moved to GBeanInstance. The GBeanMBean is not depredated,
> >>>> and
> >>>> you should use GBeanData instead and let the kernel create the
> >>>> GBeanMBean for you using the loadGBean(gbeanData, classLoader).
> >>>> Additionally, you should not use GBeanInstance directly. It is
> >>>> considered part of the internals of the GBean architecture, and is
> >>>> marked as deprecated.
> >>>>
> >>>> I also did some of the conversion from JMX exception to Geronimo
> >>>> specific exception. I only did this for setAttribute, getAttribute
> >>>> and
> >>>> invoke on the kernel. I would finish this, but I'm already getting
> >>>> in
> >>>> trouble for working on a holiday :) If someone decides to take this
> >>>> up, I suggest we think about adding some properties to the exception
> >>>> classes such as object name, attribute name, and method signature.
> >>>>
> >>>> In the process of this, I've added two new kernel services,
> >>>> ProxyManager and LifecycleMonitor. I have marked these both as
> >>>> depreciated, so we can review the interfaces. We need the basic
> >>>> functionality to for GBeans, but the interfaces and implementation
> >>>> can
> >>>> change. Once we are all happy with the services, we can removed the
> >>>> deprecated tag.
> >>>>
> >>>> BTW, before I forget the rule with ProxyManager, is if you create a
> >>>> Proxy you *must* destroy it. Otherwise, we will get a memory leak.
> >>>> I
> >>>> have some ideas on how to reduce the leaks, but it is good practice
> >>>> to
> >>>> destroy the proxy as soon as you are done with it.
> >>>>
> >>>> Happy holidays everyone,
> >>>>
> >>>> -dain
> >>>>
> >>>> --
> >>>> Dain Sundstrom
> >>>> Chief Architect
> >>>> Gluecode Software
> >>>> 310.536.8355, ext. 26
> >>>>
> >>>>
> >>
> >>
>
>
Re: GBean now JMX free
Posted by Dain Sundstrom <ds...@gluecode.com>.
That is totally weird. I did the check before I sent the email. Are
you on Java 5 and using the RI version of JMX?
-dain
On Nov 25, 2004, at 3:06 PM, Aaron Mulder wrote:
> That's because I checked in the fix. :)
>
> Aaron
>
> On Thu, 25 Nov 2004, Dain Sundstrom wrote:
>> I just did a clean checkout and rebuild.... worked perfectly for me.
>>
>> -dain
>>
>> --
>> Dain Sundstrom
>> Chief Architect
>> Gluecode Software
>> 310.536.8355, ext. 26
>>
>> On Nov 25, 2004, at 2:44 PM, Aaron Mulder wrote:
>>
>>> This change seems to have broken the security module -- I'm
>>> getting an error about only boolean attributes can have an "is"
>>> getter.
>>> I'm looking into this...
>>>
>>> Aaron
>>>
>>> On Thu, 25 Nov 2004, Dain Sundstrom wrote:
>>>> I just committed the change to the GBean code that removes the
>>>> dependency on JMX. The code now only uses the Kernel and
>>>> ObjectName.
>>>> Of course the kernel is still implemented with JMX, but the GBean
>>>> code
>>>> is not aware of this.
>>>>
>>>> To accomplish this, I moved most of the code in the
>>>> org.apache.geronimo.gbean.jmx package to
>>>> org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but
>>>> it
>>>> contains almost no logic. All of the code that was in the
>>>> GBeanMBean
>>>> has been moved to GBeanInstance. The GBeanMBean is not depredated,
>>>> and
>>>> you should use GBeanData instead and let the kernel create the
>>>> GBeanMBean for you using the loadGBean(gbeanData, classLoader).
>>>> Additionally, you should not use GBeanInstance directly. It is
>>>> considered part of the internals of the GBean architecture, and is
>>>> marked as deprecated.
>>>>
>>>> I also did some of the conversion from JMX exception to Geronimo
>>>> specific exception. I only did this for setAttribute, getAttribute
>>>> and
>>>> invoke on the kernel. I would finish this, but I'm already getting
>>>> in
>>>> trouble for working on a holiday :) If someone decides to take this
>>>> up, I suggest we think about adding some properties to the exception
>>>> classes such as object name, attribute name, and method signature.
>>>>
>>>> In the process of this, I've added two new kernel services,
>>>> ProxyManager and LifecycleMonitor. I have marked these both as
>>>> depreciated, so we can review the interfaces. We need the basic
>>>> functionality to for GBeans, but the interfaces and implementation
>>>> can
>>>> change. Once we are all happy with the services, we can removed the
>>>> deprecated tag.
>>>>
>>>> BTW, before I forget the rule with ProxyManager, is if you create a
>>>> Proxy you *must* destroy it. Otherwise, we will get a memory leak.
>>>> I
>>>> have some ideas on how to reduce the leaks, but it is good practice
>>>> to
>>>> destroy the proxy as soon as you are done with it.
>>>>
>>>> Happy holidays everyone,
>>>>
>>>> -dain
>>>>
>>>> --
>>>> Dain Sundstrom
>>>> Chief Architect
>>>> Gluecode Software
>>>> 310.536.8355, ext. 26
>>>>
>>>>
>>
>>
Re: GBean now JMX free
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
That's because I checked in the fix. :)
Aaron
On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> I just did a clean checkout and rebuild.... worked perfectly for me.
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Nov 25, 2004, at 2:44 PM, Aaron Mulder wrote:
>
> > This change seems to have broken the security module -- I'm
> > getting an error about only boolean attributes can have an "is" getter.
> > I'm looking into this...
> >
> > Aaron
> >
> > On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> >> I just committed the change to the GBean code that removes the
> >> dependency on JMX. The code now only uses the Kernel and ObjectName.
> >> Of course the kernel is still implemented with JMX, but the GBean code
> >> is not aware of this.
> >>
> >> To accomplish this, I moved most of the code in the
> >> org.apache.geronimo.gbean.jmx package to
> >> org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but it
> >> contains almost no logic. All of the code that was in the GBeanMBean
> >> has been moved to GBeanInstance. The GBeanMBean is not depredated,
> >> and
> >> you should use GBeanData instead and let the kernel create the
> >> GBeanMBean for you using the loadGBean(gbeanData, classLoader).
> >> Additionally, you should not use GBeanInstance directly. It is
> >> considered part of the internals of the GBean architecture, and is
> >> marked as deprecated.
> >>
> >> I also did some of the conversion from JMX exception to Geronimo
> >> specific exception. I only did this for setAttribute, getAttribute
> >> and
> >> invoke on the kernel. I would finish this, but I'm already getting in
> >> trouble for working on a holiday :) If someone decides to take this
> >> up, I suggest we think about adding some properties to the exception
> >> classes such as object name, attribute name, and method signature.
> >>
> >> In the process of this, I've added two new kernel services,
> >> ProxyManager and LifecycleMonitor. I have marked these both as
> >> depreciated, so we can review the interfaces. We need the basic
> >> functionality to for GBeans, but the interfaces and implementation can
> >> change. Once we are all happy with the services, we can removed the
> >> deprecated tag.
> >>
> >> BTW, before I forget the rule with ProxyManager, is if you create a
> >> Proxy you *must* destroy it. Otherwise, we will get a memory leak. I
> >> have some ideas on how to reduce the leaks, but it is good practice to
> >> destroy the proxy as soon as you are done with it.
> >>
> >> Happy holidays everyone,
> >>
> >> -dain
> >>
> >> --
> >> Dain Sundstrom
> >> Chief Architect
> >> Gluecode Software
> >> 310.536.8355, ext. 26
> >>
> >>
>
>
Re: GBean now JMX free
Posted by Dain Sundstrom <ds...@gluecode.com>.
I just did a clean checkout and rebuild.... worked perfectly for me.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Nov 25, 2004, at 2:44 PM, Aaron Mulder wrote:
> This change seems to have broken the security module -- I'm
> getting an error about only boolean attributes can have an "is" getter.
> I'm looking into this...
>
> Aaron
>
> On Thu, 25 Nov 2004, Dain Sundstrom wrote:
>> I just committed the change to the GBean code that removes the
>> dependency on JMX. The code now only uses the Kernel and ObjectName.
>> Of course the kernel is still implemented with JMX, but the GBean code
>> is not aware of this.
>>
>> To accomplish this, I moved most of the code in the
>> org.apache.geronimo.gbean.jmx package to
>> org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but it
>> contains almost no logic. All of the code that was in the GBeanMBean
>> has been moved to GBeanInstance. The GBeanMBean is not depredated,
>> and
>> you should use GBeanData instead and let the kernel create the
>> GBeanMBean for you using the loadGBean(gbeanData, classLoader).
>> Additionally, you should not use GBeanInstance directly. It is
>> considered part of the internals of the GBean architecture, and is
>> marked as deprecated.
>>
>> I also did some of the conversion from JMX exception to Geronimo
>> specific exception. I only did this for setAttribute, getAttribute
>> and
>> invoke on the kernel. I would finish this, but I'm already getting in
>> trouble for working on a holiday :) If someone decides to take this
>> up, I suggest we think about adding some properties to the exception
>> classes such as object name, attribute name, and method signature.
>>
>> In the process of this, I've added two new kernel services,
>> ProxyManager and LifecycleMonitor. I have marked these both as
>> depreciated, so we can review the interfaces. We need the basic
>> functionality to for GBeans, but the interfaces and implementation can
>> change. Once we are all happy with the services, we can removed the
>> deprecated tag.
>>
>> BTW, before I forget the rule with ProxyManager, is if you create a
>> Proxy you *must* destroy it. Otherwise, we will get a memory leak. I
>> have some ideas on how to reduce the leaks, but it is good practice to
>> destroy the proxy as soon as you are done with it.
>>
>> Happy holidays everyone,
>>
>> -dain
>>
>> --
>> Dain Sundstrom
>> Chief Architect
>> Gluecode Software
>> 310.536.8355, ext. 26
>>
>>
Re: GBean now JMX free
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
This change seems to have broken the security module -- I'm
getting an error about only boolean attributes can have an "is" getter.
I'm looking into this...
Aaron
On Thu, 25 Nov 2004, Dain Sundstrom wrote:
> I just committed the change to the GBean code that removes the
> dependency on JMX. The code now only uses the Kernel and ObjectName.
> Of course the kernel is still implemented with JMX, but the GBean code
> is not aware of this.
>
> To accomplish this, I moved most of the code in the
> org.apache.geronimo.gbean.jmx package to
> org.apache.geronimo.gbean.runtime. We still have a GBeanMBean, but it
> contains almost no logic. All of the code that was in the GBeanMBean
> has been moved to GBeanInstance. The GBeanMBean is not depredated, and
> you should use GBeanData instead and let the kernel create the
> GBeanMBean for you using the loadGBean(gbeanData, classLoader).
> Additionally, you should not use GBeanInstance directly. It is
> considered part of the internals of the GBean architecture, and is
> marked as deprecated.
>
> I also did some of the conversion from JMX exception to Geronimo
> specific exception. I only did this for setAttribute, getAttribute and
> invoke on the kernel. I would finish this, but I'm already getting in
> trouble for working on a holiday :) If someone decides to take this
> up, I suggest we think about adding some properties to the exception
> classes such as object name, attribute name, and method signature.
>
> In the process of this, I've added two new kernel services,
> ProxyManager and LifecycleMonitor. I have marked these both as
> depreciated, so we can review the interfaces. We need the basic
> functionality to for GBeans, but the interfaces and implementation can
> change. Once we are all happy with the services, we can removed the
> deprecated tag.
>
> BTW, before I forget the rule with ProxyManager, is if you create a
> Proxy you *must* destroy it. Otherwise, we will get a memory leak. I
> have some ideas on how to reduce the leaks, but it is good practice to
> destroy the proxy as soon as you are done with it.
>
> Happy holidays everyone,
>
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
>