[JBoss-dev] RE: 3.2.8 Client -> 4.0.x Compatibility

[Scott M Stark]

Title: RE: 3.2.8 Client -> 4.0.x Compatibility

Ok, so we would have:   4.0.x: MBeanServerConnection:* RMIAdaptor:add/removeNotificationListener(...)   3.2.8-: RMIAdaptor:*   3.2.8.SP1: RMIAdaptor:* MBeanServerConnection:*   The real problem is not having the hash codes, its choosing the right hash codes for the target server. You really need to be able to build the hash map based on the connection. From: Clebert Suconic Sent: Friday, February 17, 2006 10:51 PM To: Scott M Stark; Ryan Campbell; Dimitris Andreadis Cc: 'jboss-development@lists.sourceforge.net'; QA Subject: RE: 3.2.8 Client -> 4.0.x Compatibility   For doing that, you would need to implement that on [EMAIL PROTECTED], what would make only possible a communication between 3.2.8.sp1 and 4.0.4.   If we had a way to inject other hashCodes on 3.2.8.sp1, we would be able to have 3.2.8.sp1 communicating with previous versions of 4.0.4. But I don't know if that is required.         Clebert   From: Scott M Stark Sent: Fri 2/17/2006 7:00 PM To: Clebert Suconic; Ryan Campbell; Dimitris Andreadis Cc: 'jboss-development@lists.sourceforge.net'; QA Subject: RE: 3.2.8 Client -> 4.0.x Compatibility My suggestion is that the useFullHashMode be updated to include the hash of all methods in there interface inheritence tree hashed to the subinterfaces as well as the interface. So, an interface B like: interface A {    void m1(String); } interface B extends A {    void m2(String); } would have a hash map of: H(A:m1(String)) H(B:m1(String)) H(B:m2(String)) This solves the existing RMIAdaptor problem where some methods were pushed into a superinterface. The extra method hashes don't hurt anything. > -----Original Message----- > From: Clebert Suconic > Sent: Friday, February 17, 2006 3:08 PM > To: Scott M Stark; Ryan Campbell; Dimitris Andreadis > Cc: jboss-development@lists.sourceforge.net; QA > Subject: RE: 3.2.8 Client -> 4.0.x Compatibility > > I spent some time today with this issue. I just want to throw > some ideas to fix this. > > > First option: > > If you have 4.0:MarshalledInvocation.useFullHashMode=false, > and 3.2:MarshalledInvocation.useFullHashMode=false, the > testsuite should pass. > > So, we could change FullHashMode to false if some parameter > is avaible, and 3.2.8.sp1 would be compatible with 4.0.4, but > not 3.2.8. The easiest way would be have a parameter to > change the FullHashMode on 4.0 > > > > Second option: > > We could also have an interface on RMIAdaptorImpl and change > MarshalledInvocation to do something like: > >   public static Map getInterfaceHashes(Class intf) >   { >       If (intf <implements> ThatInterface) >       { >          ThatINterface that = (ThatInterface)intf.newInstance(); >           … delegate the hashCalculation to that, somehow. >       } >   } > > > I don't like this idea, but I just wanted to throw something > on the discussion, as a brain storm. > > > > Third options: > > An option also, would be to back port RMIAdaptor from 4.0.x > to 3.2.8, but that would break compatibility between 3.2.8 > and previous versions, and I don't know if there is a way to > have a selective classLoading between a newer and an older version. > > > > > Any other idea/option? > Thoughts? > > > Clebert Suconic >