Hi Sachin, Sorry about that. I only noticed it after sending the mail. I will try the link.
Tyrell ---------------------- Tyrell Perera R&D Labs, SL-ATC, Virtusa Corporation Ext: 2128 Yahoo: tyrell_perera -----Original Message----- From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 8:56 AM To: [email protected] Subject: Re: Java serizalization compatibility issues 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:[EMAIL PROTECTED] > 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. > > > >
