Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Java serizalization compatibility issues
Date: Fri, 23 Sep 2005 08:46:43 +0600
Message-ID: <785A212E11918F449D1318C61B7A9B0EF6443D@cs-mailsvr.Virtusa.com>
Thread-Topic: Java serizalization compatibility issues
Thread-Index: AcW/dxmbGIoOM8moTxmxVR8EwIOK8QAcWVgQ
From: "Tyrell Perera" <tperera@virtusa.com>
To: <sppatel2@gmail.com>
Cc: <dev@geronimo.apache.org>


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
=20

-----Original Message-----
From: Sachin Patel [mailto:sppatel2@gmail.com]=20
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=20
the lib and lib/endorsed directory into one of the eclipse plug-in, so=20
the classes can be used and referenced by the rest of the eclipse=20
plugins.  This is because eclipse can not reference classes or jars at=20
runtime that are not packaged within a plug-in and marked as visible in=20
either the plugin.xml or manifest.=20

A big problem resides as now the same jars I'm packaging must be the=20
same exact jars that reside in the target server I'm deploying.  This=20
causes a dependency on a particular server image.  If a user modifies=20
classes I reference and rebuilds their server, the plug-in is broken as=20
during deployment I'll receive error messages like the following...

Caused by: java.io.InvalidClassException:=20
org.apache.geronimo.kernel.config.ConfigurationModuleType; local class=20
incompatible: stream classdesc serialVersionUID =3D 6296527685792707191, =

local class serialVersionUID =3D -4121586344416418391
  =20
So looking at that particular class, it looks like the serialVersionUID=20
is generated by Java compiler.  This is bad as now jars/classes risk=20
compatibility between every build.  We need a solution for this.  The=20
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=20
these classes.  This problem will eventually have to be solved anyway=20
when there is multiple server support and across different versions.=20

I think this is a must fix for 1.0 as without doing so we risk product=20
migration, mixed version interoperability, tooling, possibly user=20
applications, etc...

Sachin.