RE: problem when MBean class is abstract
"Bordet, Simone" <[email protected]>
| Newsgroups | gmane.comp.java.mx4j.devel |
|---|---|
| Message-ID | <F4F4494F4618794E99E59D41C5292FFD017D865D@mnoexc01.emea.cpqcorp.net> |
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&op=click