At 02:43 AM 9/23/2005, 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
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.
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
My bad Jeremy. You are correct. I latched onto serialization and
immediately went to configuration. I realized the error of my ways this
morning when you mentioned the plugin. Doh.
Jeremy Boynes wrote:
Sachin Patel wrote: This is because eclipse can not reference classes
or jars at
Ditto, sorry. (Still not a fan of serialized configs :)
-David
On Sep 23, 2005, at 9:47 AM, Matt Hogstrom wrote:
My bad Jeremy. You are correct. I latched onto serialization and
immediately went to configuration. I realized the error of my ways
this morning when you mentioned the
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
On Sep 22, 2005, at 6:07 AM, Sachin Patel wrote:
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
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
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
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 and two you can't change it if you need to. One could
argue users shouldn't
:[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
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 and two you can't change it if you need to. One could
I think it would be nice to be able to publish using either SOAP or RMI,
and provide that option to the user in the server configuration panel in
the tools. I think RMI has better performance once we remote deployment
is supported, but SOAP is more reliable through firewalls, so thats why
it
13 matches
Mail list logo
