[ http://issues.apache.org/jira/browse/GERONIMO-1020?page=all ]
David Blevins reassigned GERONIMO-1020:
---------------------------------------
Assign To: Sachin Patel (was: David Blevins)
Patch looks good. Go for it.
> Need serialVersionUID for o.a.g.kernel.config.ConfigurationModuleType
> ---------------------------------------------------------------------
>
> Key: GERONIMO-1020
> URL: http://issues.apache.org/jira/browse/GERONIMO-1020
> Project: Geronimo
> Type: Bug
> Components: kernel
> Versions: 1.0-M5
> Reporter: Sachin Patel
> Assignee: Sachin Patel
> Priority: Critical
> Fix For: 1.0-M5
> Attachments: patch.txt
>
> 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: 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...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
