Re: RE: problem when MBean class is abstract

The RI behaviour seems reasonable to me.  An abstract class is not a 
compliant MBean, since the spec says (p33) "An MBean is a concrete Java 
class...".  Therefore an attempt to create an MBean of an abstract class 
should throw NotCompliantMBeanException.

On the other hand, the MBeanServer.instantiate operation can be used to 
create any sort of object, not just MBeans.  So it is reasonable to get 
ReflectionException from instantiate when the creation fails because the 
class is abstract.  Conceptually, an attempt to call registerMBean with 
an instance of an abstract class would get NotCompliantMBeanException, 
just as with createMBean, so there is no inconsistency.  Of course, 
there are no instances of abstract classes so this can't happen.

Regards,
Éamonn McManus   JMX Spec Lead   +33 476 188 352


Bordet, Simone wrote:
> Hi, 
> 
> 
>>-----Original Message-----
>>From: Jeremy Boynes [mailto:[email protected]] 
>>Sent: Wednesday, February 02, 2005 23:39
>>To: Bordet, Simone
>>Subject: problem when MBean class is abstract
>>
>>Hi there
>>
>>I've run into a problem testing the case when the class for 
>>an MBean is abstract and hence can't be instantiated.
>>
>>When MBS.instantiate() is called both MX4J and JDK1.5 throw a 
>>ReflectionException; however, when createMBean() is called 
>>MX4J still throws ReflectionException but the RI throws a 
>>NotCompliantMBeanException.
>>
>>Reading the spec (the JavaDoc to be precise) it is not clear 
>>to me why the RI is throwing a different exception. Do you 
>>think this might be a bug in MX4J or an ambiguity in the spec 
>>(and TCK)?
> 
> 
> I think is a RI bug, and that the behavior should be consistent, also because it has always been said that createMBean() == instantiate() + registerMBean() (for example also for permission checking).
> 
> Eamonn ?
> 
> Simon
> 
> 
>>I think it's possible to hack createMBean to check for an 
>>InstantiationException buried inside the ReflectionException 
>>it gets from instantiateImpl() but that seems clunky. 
>>However, the alternative would be to change 
>>MBeanServerInterceptor to allow the original exception to 
>>propogate back up so that createMBean and instantiate can 
>>handle it appropriately and changing the siganture for the 
>>interceptor seems like a big thing.
>>
>>Thanks
>>--
>>Jeremy
>>
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id396&opclick
> _______________________________________________
> Mx4j-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mx4j-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click