Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: 216.136.174.113 is neither permitted
 nor denied by domain of sppatel2@gmail.com)
Message-ID: <43336EA2.60804@gmail.com>
Date: Thu, 22 Sep 2005 22:55:30 -0400
From: Sachin Patel <sppatel2@gmail.com>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Java serizalization compatibility issues
References: <785A212E11918F449D1318C61B7A9B0EF6443D@cs-mailsvr.Virtusa.com>
In-Reply-To: <785A212E11918F449D1318C61B7A9B0EF6443D@cs-mailsvr.Virtusa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 
thread.

Thanks.

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 [mailto:sppatel2@gmail.com] 
> 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: 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.
>
>
>
>