Sachin Patel wrote: "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."
This thread wasn't about configuration files but about communication
between JVMs. Sachin's plugin fails when talking to the server because
there are different versions of the classes in the Eclipse client and in
the running server.
RMI is the only transport guaranteed to be available by the JMX remoting
specification. To use it the classes passed on the wire must be
Serializable. We do not control the versions used on either end and
hence need to ensure that skewed versions can interoperate. This means
following the rules for serialization compatibility (such as adding
serialUIDs).
--
Jeremy
Bill Stoddard wrote:
Matt Hogstrom wrote:
Not being totally familiar with all the nuances in G WRT to
serialization my comments should be taken with a grain of salt. From
my perspetive there are two major problems with serialized data. One,
its very fragile
Yes.
and two you can't change it if you need to. One could argue users
shouldn't be changing it but in extreme circumstances it is unavoidable.
I'd vote for the move to XML (ouch, did I say that?)
Matt
My inclination as well. I've been scratching my head trying to
understand 'why serialization?' rather than nice, flat, intuitive text
files. There may be a very good answer I just don't what it is.
Jeremy Boynes wrote:
Sachin's problem is not related to configuration persistence but to
the serialization of classes between plugin and server when using JMX
remoting over RMI.
The upshot of it all is unless we are going to ditch all use of
serialization and replace it with XML then we need to exercise the
necessary discipline and version the classes involved.
--
Jeremy
