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.
