Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@ca...> - 2004-11-17 11:30:37
|
All, I am considering removing the notion of the MBeanInvoker from Spring JMX along with the Spring implementation of ModelMBean. There are two reasons for this: 1. I am not sure of the value offered by this approach given that the performance difference between the JDK invoker and the CGLIB invoker is hardly noticeable as shown by the tests in the sandbox. 2. All JMX implementations come with RequiredModelMBean which is already supported by Spring JMX - we don't really need another implementation if there is no benefit and I would prefer not to have keep modifying the ModelMBeanImpl class to keep up with the JMX spec. Originally, I had thought that having our own ModelMBean would enable us to improve performance but that turns out not to be true, instead we just have a model that is more complicated. I propose to remove the MBeanInvoker concept altogether and use the RequiredModelMBean class as the standard but provide the ability for other implementations to be plugged in a later date should the need arise in the future. What are your thoughts? Rob P.S. - Keith - I know you said this from the beginning and you were right. Don't say I told you so :) |
|
From: Rod J. <ro...@in...> - 2004-11-17 12:52:18
|
+1. Simplification is good! Rob Harrop wrote: > All, > > I am considering removing the notion of the MBeanInvoker from Spring JMX > along with the Spring implementation of ModelMBean. There are two > reasons for this: > > 1. I am not sure of the value offered by this approach given that the > performance difference between the JDK invoker and the CGLIB invoker is > hardly noticeable as shown by the tests in the sandbox. > 2. All JMX implementations come with RequiredModelMBean which is already > supported by Spring JMX - we don't really need another implementation if > there is no benefit and I would prefer not to have keep modifying the > ModelMBeanImpl class to keep up with the JMX spec. > > Originally, I had thought that having our own ModelMBean would enable us > to improve performance but that turns out not to be true, instead we > just have a model that is more complicated. I propose to remove the > MBeanInvoker concept altogether and use the RequiredModelMBean class as > the standard but provide the ability for other implementations to be > plugged in a later date should the need arise in the future. > > What are your thoughts? > > Rob > > P.S. - Keith - I know you said this from the beginning and you were > right. Don't say I told you so :) > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > -- ____________________________________________________ Rod Johnson Interface21 - Spring Services from the Source http://www.springframework.com Founder, Spring Framework: http://www.springframework.org Author, "Expert One-on-One J2EE Development Without EJB" (May 2004, with Juergen Hoeller). http://www.amazon.com/exec/obidos/ASIN/0764558315/ Author, "Expert One-on-One J2EE Design and Development" (October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/ ____________________________________________________ Interface21 Limited Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY Registered in England and Wales No. 5187766 ____________________________________________________ |
|
From: Colin S. <col...@ex...> - 2004-11-17 15:35:11
|
+1 Rob Harrop wrote: > All, > > I am considering removing the notion of the MBeanInvoker from Spring > JMX along with the Spring implementation of ModelMBean. There are two > reasons for this: > > 1. I am not sure of the value offered by this approach given that the > performance difference between the JDK invoker and the CGLIB invoker > is hardly noticeable as shown by the tests in the sandbox. > 2. All JMX implementations come with RequiredModelMBean which is > already supported by Spring JMX - we don't really need another > implementation if there is no benefit and I would prefer not to have > keep modifying the ModelMBeanImpl class to keep up with the JMX spec. > > Originally, I had thought that having our own ModelMBean would enable > us to improve performance but that turns out not to be true, instead > we just have a model that is more complicated. I propose to remove the > MBeanInvoker concept altogether and use the RequiredModelMBean class > as the standard but provide the ability for other implementations to > be plugged in a later date should the need arise in the future. > > What are your thoughts? > > Rob > > P.S. - Keith - I know you said this from the beginning and you were > right. Don't say I told you so :) > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Keith D. <kd...@cs...> - 2004-11-17 15:50:56
|
+1, too. Using RequiredModelMBean should let us more easily take advantage of other JMX implementations 'value-add' capabilities--since each impl is required to ship a RequiredModelMBean implementation. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Colin Sampaleanu Sent: Wednesday, November 17, 2004 10:35 AM To: spr...@li... Subject: Re: [Springframework-developer] Simplification of Spring JMX +1 Rob Harrop wrote: > All, > > I am considering removing the notion of the MBeanInvoker from Spring > JMX along with the Spring implementation of ModelMBean. There are two > reasons for this: > > 1. I am not sure of the value offered by this approach given that the > performance difference between the JDK invoker and the CGLIB invoker > is hardly noticeable as shown by the tests in the sandbox. > 2. All JMX implementations come with RequiredModelMBean which is > already supported by Spring JMX - we don't really need another > implementation if there is no benefit and I would prefer not to have > keep modifying the ModelMBeanImpl class to keep up with the JMX spec. > > Originally, I had thought that having our own ModelMBean would enable > us to improve performance but that turns out not to be true, instead > we just have a model that is more complicated. I propose to remove the > MBeanInvoker concept altogether and use the RequiredModelMBean class > as the standard but provide the ability for other implementations to > be plugged in a later date should the need arise in the future. > > What are your thoughts? > > Rob > > P.S. - Keith - I know you said this from the beginning and you were > right. Don't say I told you so :) > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jas...@ma...> - 2004-11-18 08:21:06
|
Sounds great to me. Anyone any idea of when the JMX stuff is gonna be released? I'm keen to start using it... On 17 Nov 2004, at 11:30, Rob Harrop wrote: > All, > > I am considering removing the notion of the MBeanInvoker from Spring > JMX along with the Spring implementation of ModelMBean. There are two > reasons for this: > > 1. I am not sure of the value offered by this approach given that the > performance difference between the JDK invoker and the CGLIB invoker > is hardly noticeable as shown by the tests in the sandbox. > 2. All JMX implementations come with RequiredModelMBean which is > already supported by Spring JMX - we don't really need another > implementation if there is no benefit and I would prefer not to have > keep modifying the ModelMBeanImpl class to keep up with the JMX spec. > > Originally, I had thought that having our own ModelMBean would enable > us to improve performance but that turns out not to be true, instead > we just have a model that is more complicated. I propose to remove the > MBeanInvoker concept altogether and use the RequiredModelMBean class > as the standard but provide the ability for other implementations to > be plugged in a later date should the need arise in the future. > > What are your thoughts? > > Rob > > P.S. - Keith - I know you said this from the beginning and you were > right. Don't say I told you so :) > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > James ------- http://radio.weblogs.com/0112098/ |
|
From: Rob H. <ro...@ca...> - 2004-11-18 08:37:55
|
I'm getting it ready for 1.2 - not sure when that will be though. I would guess late December at the earliest. I still have to include JSR-175 support and a couple of other little features but I fixed quite a few problems yesterday and moved many of the concepts more inline with those already existing in Spring. I'm also going to try for compatibility with 1.0 as much as possible which might mean refactoring the proxy classes a little since they rely on some 1.2 specific interfaces to support JSR-160 proxies. Rob jas...@ma... wrote: > Sounds great to me. > > Anyone any idea of when the JMX stuff is gonna be released? I'm keen > to start using it... > > > On 17 Nov 2004, at 11:30, Rob Harrop wrote: > >> All, >> >> I am considering removing the notion of the MBeanInvoker from Spring >> JMX along with the Spring implementation of ModelMBean. There are two >> reasons for this: >> >> 1. I am not sure of the value offered by this approach given that the >> performance difference between the JDK invoker and the CGLIB invoker >> is hardly noticeable as shown by the tests in the sandbox. >> 2. All JMX implementations come with RequiredModelMBean which is >> already supported by Spring JMX - we don't really need another >> implementation if there is no benefit and I would prefer not to have >> keep modifying the ModelMBeanImpl class to keep up with the JMX spec. >> >> Originally, I had thought that having our own ModelMBean would enable >> us to improve performance but that turns out not to be true, instead >> we just have a model that is more complicated. I propose to remove >> the MBeanInvoker concept altogether and use the RequiredModelMBean >> class as the standard but provide the ability for other >> implementations to be plugged in a later date should the need arise >> in the future. >> >> What are your thoughts? >> >> Rob >> >> P.S. - Keith - I know you said this from the beginning and you were >> right. Don't say I told you so :) >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: InterSystems CACHE >> FREE OODBMS DOWNLOAD - A multidimensional database that combines >> robust object and relational technologies, making it a perfect match >> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > James > ------- > http://radio.weblogs.com/0112098/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: InterSystems CACHE > FREE OODBMS DOWNLOAD - A multidimensional database that combines > robust object and relational technologies, making it a perfect match > for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
