The results we have on the matrix testsuite are what I expected: http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-compatibility-matr ix/20060512154233/results/index.html
I will now find a way to remove PooledInvokers being tested under 4.0.2- BTW: There is another failure on JMS that I don't have anything to do with that: http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-compatibility-matr ix/20060512154233/results/org/jboss/test/compatibility/test/matrix/Matri xTestContainer(jms_3_2_x).html Clebert Suconic -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Friday, May 12, 2006 2:23 PM To: Scott M Stark; jboss-development@lists.sourceforge.net Subject: [JBoss-dev] RE: JBAS-2267 is the last task!!! It's already commited, I'm waiting next version compatibility testsuite build to see if this is working fine. -----Original Message----- From: Scott M Stark Sent: Friday, May 12, 2006 12:10 PM To: Clebert Suconic; 'jboss-development@lists.sourceforge.net' Subject: RE: JBAS-2267 is the last task!!! Ok, fine. > -----Original Message----- > From: Clebert Suconic > Sent: Friday, May 12, 2006 10:03 AM > To: Scott M Stark; jboss-development@lists.sourceforge.net > Subject: JBAS-2267 is the last task!!! > > OptimizedOutputStream and OptimizedInputStream didn't send > versioning information before. > > These were overriding metadata discovery by always rebuilding > it from current class, what means if a field is added > ObjectInputStream will "think" the streaming should have everything. > > > Then my changes basically consisted of fixing writeClassDef > and readClassDef by falling back to the defaults classes, if > a System property is defined. From now on if a change in a > class happens we will have much better chances of being > compatible between versions. > > But now the problem is on ServerAddress. That class had a > field added on 4.0.3, (and I thought the field was added on > 4.0.4.rc1), and there is no way to make Pooled invokers > compatible on 4.0.x <-> 4.0.2, unless we break 4.0.x <-> 4.0.3. > > > I would like to keep PooledInvokers broken between > 4.0.2<->4.0.x, but I can't take that decision alone. > > There is no way to hack this to keep it always work. I almost > got a way to write a hack (really a hack) using > Serialization's protocol on a private writeObject and private > readObject method, but on the end it wasn't possible at al > because the presence of writeObject was telling serialization > to send an extra byte. And even that way, the hack was so > ugly that I didn't want to commit. > > So, can I proceed on breaking 4.0.2 <->4.0.x on pooled > invokers and having it working after 4.0.3? > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
