geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: Java serizalization compatibility issues
Date Fri, 23 Sep 2005 02:55:30 GMT
Hi. Tyrell,  I've already fixed the link.  In the future, please start a 
new thread when discussing a new topic, or respond with your original 


Tyrell Perera wrote:
> Hi Sachin,
> I'm interested in contributing to the Eclipse tools project of Geronimo.
> I have sent a mail before asking where to find more information, since
> the link given to download the unstable build of the plug-in was broken
> when I tried.
> Can you please give me some pointers on where to begin and to get hold
> of the source for the plug-in?
> Tyrell
> -----Original Message-----
> From: Sachin Patel [] 
> Sent: Thursday, September 22, 2005 7:08 PM
> To: geronimo-dev
> Subject: Java serizalization compatibility issues
> 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...
> Sachin.

View raw message