Re: RequiredModelMBean

Roland,

An implementation of a JSR, such as JSR 3 (JMX API), must exactly 
respect the Java-language signatures of every class specified by that 
JSR.  It would not be legal for the MX4J implementation to add any new 
methods or change the publicly-visible inheritance of any class in the 
javax.management.* namespace.

This is of course to ensure portability between implementations.  If you 
depend on things that MX4J provides and that are not specified for other 
implementations, then it is logical for you to have to say this 
explicitly by referencing mx4j.* classes.

Regards,
Éamonn McManus   JMX Spec Lead   http://weblogs.java.net/blog/emcmanus/


Roland Huss wrote:
> Hi Simon,
> 
> Bordet, Simone wrote:
> 
> 
>>That this is not possible since the JMX specification requires
>>RequiredModelMBean to inherit and implement from the classes and
>>interfaces defined by the specification.
>>Therefore it cannot extend MX4JModelMBean.
> 
> 
> AFAIK a ModelMBean implementation needs to *implement* the interface ModelMBean but
> doesn't need to inherit from any base class. BTW, this is true for Mx4j's
> RequiredModelMBean as well which doesn't have any special super class.
> 
> So the following setup should work and gives a chance to use Mx4j's ModelMBean
> implementation with other JMX implementations (JBoss, RI):
> 
> package mx4j;
> 
> public class Mx4jModelMBean
>        implements ModelMBean, MBeanRegistration, NotificationEmitter {
> 
>   /* Implementation of a ModelMBean */
>   ...
> }
> 
> ===========================================================================
> 
> package javax.management.modelmbean;
> 
> public class RequiredModelMBean extends mx4j.Mx4jModelMBean { /* nothing here */ }
> 
> ===========================================================================
> 
> 
>>Given this, I take the chance to say one more time what I personally
>>think of ModelMBeans, and especially RequiredModelMBean: think twice
>>before using them. 
>>These classes suffer from long standing bugs in the specifications,
>>implementations, have incoherent behavior and even if you write
>>something that works in one implementation, you can bet that you change
>>the implementation and it will not work. They work, but hey, don't ask
>>for help :)
> 
> 
> Could you give me some more details why ModelMBeans are so evil ? (beside the fact that
> forcing an JMX implementation to provide *classes* from the javax.management namespace is
> not really nice).
> 
> We are using Spring for JMX integration which in turn uses ModelMBeans to expose the
> management interface, so I really would like to know what's the problem with ModelMBeans
> before I'm going to ride a nearly dead horse ;-)
> 
> thanx....


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar