So if you are not aware, I'm pulling in and packaging several jars from
the lib and lib/endorsed directory into one of the eclipse plug-in, so
the classes can be used and referenced by the rest of the eclipse
plugins. This is because eclipse can not reference classes or jars at
runtime that are not packaged within a plug-in and marked as visible in
either the plugin.xml or manifest.
A big problem resides as now the same jars I'm packaging must be the
same exact jars that reside in the target server I'm deploying. This
causes a dependency on a particular server image. If a user modifies
classes I reference and rebuilds their server, the plug-in is broken as
during deployment I'll receive error messages like the following...
Caused by: java.io.InvalidClassException:
org.apache.geronimo.kernel.config.ConfigurationModuleType; local class
incompatible: stream classdesc serialVersionUID = 6296527685792707191,
local class serialVersionUID = -4121586344416418391
So looking at that particular class, it looks like the serialVersionUID
is generated by Java compiler. This is bad as now jars/classes risk
compatibility between every build. We need a solution for this. The
only other option I'm aware of is for these serializable classes to hard
code and explicity assign a value. Of course we must then assue that we
manually maintain backward compatibility to support the N-2 model for
these classes. This problem will eventually have to be solved anyway
when there is multiple server support and across different versions.
I think this is a must fix for 1.0 as without doing so we risk product
migration, mixed version interoperability, tooling, possibly user
applications, etc...
Sachin.
- Java serizalization compatibility issues Sachin Patel
-
