[manik]

Agreed that some exceptions may get serialised as return values, but as you pointed out, this is not in the list of errors.

As for other JGroups classes, those that are transported across the wire are marshalled using the TreeCacheMarshaller in 1.4.0, so this is not a problem when talking to 1.4.x.

This does break down in one scenario though; and this is when we use region-based marshalling (JBC 1.2.x/1.3.x) which forces Java serialization on the payload, including JGroups classes. (When not using region-based marshalling, JGroups Streamable interface is used, which does not make use of Java seriaization)

[manik]

As for the other errors you see, we will need an exclusion list for classes that need not be compared, such as:

 org.jboss.serial.objectmetamodel.DataContainer

As for classes such as

 org.jboss.cache.marshall.JBCMethodCall

I have raised a JIRA task to set the svuid to be the same as previous 1.4.x releases.

http://jira.jboss.com/jira/browse/JBCACHE-917

As for these classes:

 org.jboss.cache.OptimisticTreeNode
 org.jboss.cache.optimistic.DefaultDataVersion
 org.jboss.cache.optimistic.FqnComparator

I have added a task to investigate these. Apart from DataVersion, they are not streamed and should not be serializable at all. For the 2.x.x series, I will make sure they are not serializable, and for 1.4.x, make sure they have compatible svuid props.

See http://jira.jboss.com/jira/browse/JBCACHE-918

[manik]

Ok, we have a problem with these classes:

 org.jboss.cache.OptimisticTreeNode
 org.jboss.cache.optimistic.DefaultDataVersion
 org.jboss.cache.optimistic.FqnComparator

They currently (1.4.1.CR1) have svuid fields set to be compatible with 1.4.0, which is not compatible with 1.3.0. If I change these to be compatible with 1.3.0, it will break compat with 1.4.0, which I think is more important.

At the end of the day though, minor version updates are allowed to break wire-level compat, as long as the API is not broken. So 1.3.0 -> 1.4.0 causing a serialization error should be ok, I suppose? Not ideal, and this should be minimised as far as possible, but I can't see a way around this now that this is out in 1.4.0.

At least having a test suite like this will mean this shouldn't happen in future.

[pavel.tsekov]

Ok, we have a problem with these classes:

 org.jboss.cache.OptimisticTreeNode
 org.jboss.cache.optimistic.DefaultDataVersion
 org.jboss.cache.optimistic.FqnComparator

Ok. So, I'll blacklist them when checking 1.4.x compatibility against 1.3.x.

[manik]

+1.

Thanks.

[ryan.campbell]

Manik,

Where should we document this test case? A readme in the src/etc folder? Somewhere else?

Thanks,
Ryan

[pavel.tsekov]

Agreed that some exceptions may get serialised as return values, but as you pointed out, this is not in the list of errors.

As for other JGroups classes, those that are transported across the wire are marshalled using the TreeCacheMarshaller in 1.4.0, so this is not a problem when talking to 1.4.x.

So, if I got it right this means that it is safe to exclude all jgroups classes excepth "*Exception" when testing agains 1.4.0 GA ?

This does break down in one scenario though; and this is when we use region-based marshalling (JBC 1.2.x/1.3.x) which forces Java serialization on the payload, including JGroups classes. (When not using region-based marshalling, JGroups Streamable interface is used, which does not make use of Java seriaization)

Does 1.4.x support region-based marshalling i.e. for backward compatibility with older versions i.e. is it possible to run 1.4.x with 1.3.x so that they'll exchange java serialized objects ?

[manik]

So, if I got it right this means that it is safe to exclude all jgroups classes excepth "*Exception" when testing agains 1.4.0 GA ?

Yes

Does 1.4.x support region-based marshalling i.e. for backward compatibility with older versions i.e. is it possible to run 1.4.x with 1.3.x so that they'll exchange java serialized objects ?

Yes. This is how backward compat is maintained, and in such a case, the same version of JGroups needs to be used on both nodes, so svuid problems on the JGroups level goes away.

[manik]

Manik,

Where should we document this test case? A readme in the src/etc folder? Somewhere else?

Thanks,
Ryan

For JUnit tests, I normally have a list of "known failures" as a set of test excludes in build.xml, each exclude listed with a comment pointing to the relevant JIRA task. These excludes are passed to JUnit tasks so these tests are excluded from reports (such as the cruise control target).

Perhaps a similar approach could be adopted here? Better still, maybe this could be an external properties file that build.xml reads and excludes? We could then use the same external file for known JUnit excludes as well?

[pavel.tsekov]

Thanks for the explanation Manik! :) I'll adjust the code accordingly.