[ mx4j-Bugs-1016117 ] Signature compliance for javax.management package

"SourceForge.net" <[email protected]>
Newsgroups gmane.comp.java.mx4j.devel
Message-ID <[email protected]> 
Bugs item #1016117, was opened at 2004-08-25 16:26
Message generated for change (Comment added) made by fbenoit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1016117&group_id=47745

Category: JMX implementation
Group: Release 2.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Florent BENOIT (fbenoit)
Assigned to: Simone Bordet (biorn_steedom)
Summary: Signature compliance for javax.management package

Initial Comment:
	Hi,

Signature of JMX api (inside Mx4J) differs from the JSR
160 api
Mx4j is included in JOnAS (http://jonas.objectweb.org).

To be fully J2EE compliant, the signatures of
javax.management packages should be compliant too with
the J2EE specification.

For example :

For the class : javax.management.MBeanFeatureInfo

http://java.sun.com/j2ee/1.4/docs/api/javax/management/MBeanFeatureInfo.html
It should only implements Serializable but Mx4J class
implements both Serializable and Cloneable :
http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/javax/management/MBeanFeatureInfo.java?rev=1.5&view=auto


javax.management.AttributeChangeNotificationFilter
should implements both NotificationFilter and
Serializable interfaces
http://java.sun.com/j2ee/1.4/docs/api/javax/management/AttributeChangeNotificationFilter.html
even if NotificationFilter class extends Serializable.


The classes
javax.management.modelmbean.ModelMBeanAttributeInfo,
javax.management.modelmbean.ModelMBeanConstructorInfo,
javax.management.modelmbean.ModelMBeanNotificationInfo
should implement javax.management.DescriptorAccess and
java.lang.Cloneable
http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/ModelMBeanAttributeInfo.html
(even if superclass MBeanAttributeInfo already
implements Serializable).



javax.management.modelmbean.ModelMBeanInfo should not
implement Cloneable interface
http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/javax/management/modelmbean/ModelMBeanInfo.java?rev=1.2&view=auto
http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/ModelMBeanInfo.html
Also, it should not contain the method getConstructor()


javax.management.modelmbean.ModelMBeanInfoSupport
should implement both ModelMBeanInfo and Serializable
interface 
http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/ModelMBeanInfoSupport.html

javax.management.modelmbean.RequiredModelMBean has a
wrong signature method for
removeAttributeChangeNotificationListener(javax.management.NotificationListener,java.lang.String)
public void
removeAttributeChangeNotificationListener(NotificationListener
listener, String attributeName) throws
RuntimeOperationsException, ListenerNotFoundException
should also throw MBeanException
http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/RequiredModelMBean.html#removeAttributeChangeNotificationListener(javax.management.NotificationListener,%20java.lang.String)

I wonder if you could change these signatures, need a
patch or something else in order to be 100% compliant
with API.

Regards,

Florent.

JOnAS project.

----------------------------------------------------------------------

>Comment By: Florent BENOIT (fbenoit)
Date: 2004-09-01 08:35

Message:
Logged In: YES 
user_id=1110913

The TCK tests on signature will not change soon, so as you
don't want to change signature on duplicate imports (and I
can understand this as this is useless), we will change this
on our side for a while before the tests changed.

Regards,

Florent

----------------------------------------------------------------------

Comment By: Florent BENOIT (fbenoit)
Date: 2004-08-30 15:22

Message:
Logged In: YES 
user_id=1110913

Concerning other ModelMBean*Info, like 
ModelMBeanOperationInfo, the reference implementation is
correct and don't implement again Cloneable interface :
http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/ModelMBeanOperationInfo.html

I will report the problem on signature compliance on TCK.
(implementing twice an interface).

Also, what do you think the problem on IIOP (last part of
previous message).


----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-08-30 14:06

Message:
Logged In: YES 
user_id=128193

Florent, with regards to your patch file:

+ AttributeChangeNotificationFilter already implements
Serializable, it's a bug in the TCK. Not changed.
+ MBeanAttributeInfo already implements Serializable, it's a
bug in the TCK. Not changed.
+ MBeanConstructorInfo already implements Serializable, it's
a bug in the TCK. Not changed.
+ MBeanNotificationInfo already implements Serializable,
it's a bug in the TCK. Not changed.
+ MBeanOperationInfo already implements Serializable, it's a
bug in the TCK. Not changed.
+ MBeanParameterInfo already implements Serializable, it's a
bug in the TCK. Not changed.
+ MBeanPermission: removed the modifier "final".
+ MBeanServerPermission: removed the modifier "final".
+ MBeanTrustPermission: removed the modifier "final".
+ NotificationFilterSupport already implements Serializable,
it's a bug in the TCK. Not changed.
+ ModelMBeanInfo: removed inheritance from Cloneable. Note
that this does not change the fact that people can call
clone(), since the interface has this method (but does not
implements Cloneable - which is IMHO an implementation
mistake). However, for historical reasons I changed it to be
compliant to avoid some mad did this in the code: Cloneable
c = modelMBeanInfo. Note also that this is plain silly since
Cloneable is a tag interface, but who knows...
+ ModelMBeanAttributeInfo already implements Cloneable, it's
a bug in the TCK. Not changed.
+ ModelMBeanConstructorInfo already implements Cloneable,
it's a bug in the TCK. Not changed.
+ ModelMBeanNotificationInfo already implements Cloneable,
it's a bug in the TCK. Not changed.
+ ModelMBeanOperationInfo: note that this class has the same
"glitches" of the other ModelMBean*Info classes, but the TCK
does not catch it (or you did not report it). Not changed.
+ ModelMBeanInfoSupport already implements Serializable,
it's a bug in the TCK. Not changed.
+ For the monitor classes, you should give me few more days,
since I am rewriting them, changing the class declaration as
your diff reports.

I spoke long ago with Eamonn McManus (JMX spec lead) about
the bugs in the TCK. I've never had the chance to run it
against MX4J (could not afford it, nor MX4J is a legal
entity that can ask the open source version), but - if I
remember well - we said that obvious bugs in the TCK would
not be considered show-stoppers for the compliance.

Unless someone demonstrates me that inheritance of
Serializable is forgot in subclasses, I'm not keen to change
MX4J. 
If someone questions the compliance for this reason, I'd
like to participate in the discussion.

----------------------------------------------------------------------

Comment By: Florent BENOIT (fbenoit)
Date: 2004-08-30 12:27

Message:
Logged In: YES 
user_id=1110913

  Hi,

Sorry for this late answer.
Yes TCK is run against MX4J. (And if you don't know, JMX
tests pass with the latest TCK/exclude list)

But there are still some problems on signature.(CVS version).

Note that Cloneable interface must not be a super interface
of javax.management.modelmbean.ModelBeanInfo interface.

http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/core/javax/management/modelmbean/ModelMBeanInfo.java?rev=1.3&view=markup

http://java.sun.com/j2ee/1.4/docs/api/javax/management/modelmbean/ModelMBeanInfo.html
Note that the clone() method is used in RequiredModelMBean
class so it should impact changes.
for example :
m_modelMBeanInfo = (ModelMBeanInfo)modelMBeanInfo.clone();


I attach a patch in order that you see the signatures which
are still incorrect.

Also, I have used CVS version to get the changes and I have
a problem on IIOP as (in the build.xml) we run first rmic
with iiop and then iiop with POA model.
But if we don't want to use POA, there is a problem as the
classes are replaced by poa classes.
So POA model may be an option of compilation ? or model
without POA could be an option ?


Regards,

Florent

----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-08-28 14:42

Message:
Logged In: YES 
user_id=128193

There were few bugs in the MX4J signature compliance tests
that hid errors behind warnings.
I have found few others signature mismatches, fixed and
committed them all.
I am closing this bug as fixed. If you have further
information, don't hesitate to reopen it.
Thanks !

----------------------------------------------------------------------

Comment By: Simone Bordet (biorn_steedom)
Date: 2004-08-26 16:50

Message:
Logged In: YES 
user_id=128193

What do you mean with "fully J2EE compliant" ? Are you
running the JMX TCK against MX4J ?
If so, I hope Sun will fix the TCK bugs or at least ignore
the failures and grant compliance.
As for the MX4J bugs, I'm going to fix them, they're trivial
changes.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=1016117&group_id=47745


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.