-
1. Re: Serialization Compatibility Tests
We should test both explicit and implicit serialversionUIDs. We want to know about a breaking change whether it was intentional or not.
-
-
3. Re: Serialization Compatibility Tests
As far as I am aware, you should have sufficient requirements for an initial version. If any other questions come up, just post them to this thread.
-
4. Re: Serialization Compatibility Tests
Ryan, I have vague idea of what had to be done. Instead of doing something and then waiting for people to complain I prefer to do the asking first. I hope you don't have problem with that.
Now back to the topic...
1) The original tool creates a database of serialVersionUIDs for the classes found in the java "javax" package . Do we need this for JBossCache ?
2) Are there any known serialization issues between the different
JBossCache versions ? If you know of such issues, please, let me
know so I can blacklist the classes in question. -
5. Re: Serialization Compatibility Tests
1. If these classes are included in any of the jars included in the JBossCache distribution, yes.
2. http://jira.jboss.com/jira/browse/JBAS-3772 is the issue I'm aware of. -
6. Re: Serialization Compatibility Tests
The problem is that I don't really understand why only those classes ("javax") from the java runtime are processed while the others are left out. Maybe in jboss some instances of classes from the "javax" package are serialized - but is this the case for JBossCache ?
-
7. Re: Serialization Compatibility Tests
The javax classes validated for jbossas are from the javaee namespace. Since we supply those we need to validate them. Any javax classes in the jdk are a function of jdk versions, and compatibility at that level is a jdk compatibility problem.
-
8. Re: Serialization Compatibility Tests
From a JBC standpoint, we should look at both implicit and explicit svuids. The namespace to scan should be org.jboss.cache.*
-
9. Re: Serialization Compatibility Tests
Pretty much none of the Exception classes and many other classes in mainline aren't marked with an explict serial version ID. Might be worth putting them in for JBossCache 2.0.
-
10. Re: Serialization Compatibility Tests
Manik,
If you exclude classes outside of org.jboss.cache, aren't you taking the risk that a 3rd party library could kill backwards compatibility?
That's why we should default to greedy comparisons, like we do on AS, and only remove packages by exception when we determine they are not serialized or don't otherwise present compatibility issues. -
11. Re: Serialization Compatibility Tests
External library classes are not serialized or shipped around in JBC, except for the case of JGroups classes. For JGroups, I think a similar sviud policy and QA step should be in place too, so when, for example, JGroups 2.4 is certified compatible with 2.4.1, I can ship JBC with either and expect the same compatibility.
-
12. Re: Serialization Compatibility Tests
It'd be cool to be able to capture what classes (thirdparty or otherwise) were getting serialized when you ran your test suite.
-
13. Re: Serialization Compatibility Tests
External library classes are not serialized or shipped around in JBC, except for the case of JGroups classes.
Ok, if this is the case, we only want to compare org.jboss.cache and org.jgroups. -
14. Re: Serialization Compatibility Tests
I wan to start adding source files related to the SVUID tests to the source tree. There is this tool that builds a database of SVUIDs called SerialVersionUID. It consist of two source files and I've put them under varia/src/org/jboss/tools/ under the JBossCache root locally. Then there is the test itself which I put under tests/compatibility/org/jboss/cache/compatibility/. Is this acceptable ? If not - please, propose a proper directory structure so I can move forward.