geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <>
Subject [jira] Commented: (GERONIMO-1020) Fix java serialization compatibility issues across product
Date Thu, 22 Sep 2005 22:06:29 GMT
    [ ] 

Aaron Mulder commented on GERONIMO-1020:

I don't think this is a useful report.  It needs a list of specific classes, or you need to
submit bugs for speecific classes as you come across them, or something.  As is, it can never
be closed, because we'll never add a serial version ID to every class in the product and we'll
never know if the ones we've missed will cause problems.  So I think we need to handle specific
classes as we become aware of them.

Are you OK changing this report to be "Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType"?

> Fix java serialization compatibility issues across product
> ----------------------------------------------------------
>          Key: GERONIMO-1020
>          URL:
>      Project: Geronimo
>         Type: Bug
>     Reporter: Sachin Patel
>     Priority: Critical

> From dev list post...
> 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: 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...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message