Home » Eclipse Projects » Eclipse Platform » [De]serialization of objects in plugin
| [De]serialization of objects in plugin [message #331737] |
Thu, 18 September 2008 19:39  |
Eclipse User |
|
|
|
Originally posted by: alexm.xxx.yyy
All:
Similar problems have been brought up and discussed here, but I still do
not see a clear solution.
One of my plugins (A) serializes an object (DataBucket) _from another
plugin (B)_ and saves it in a file. Trying to deserialize it back,
however, throws the ClassNotFoundException. I experimented with bundle
exports in the manifest file, but the only solution that worked was this:
1. Get a valid class loader from the plugin B that defines the
serialized object:
ClassLoader cl = DataBucket.class.getClassLoader();
2. subclass ObjectInputStream to override its resolveClass() method, and
make it use the class loader from step 1:
public class MyObjectInputStream extends ObjectInputStream {
private ClassLoader classLoader;
public MyObjectInputStream(InputStream in, ClassLoader cl)
throws IOException {
super(in);
classLoader = cl;
}
@Override
protected Class<?> resolveClass(final ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
String name = desc.getName();
try {
Class<?> klass = Class.forName(name, false, classLoader);
return klass;
} catch (ClassNotFoundException ex) {
throw ex;
}
}
}
3. In plugin A, deserialize the object, using MyObjectInputStream:
ObjectInputStream in = new MyObjectInputStream(inputStream,
DataBucket.class.getClassLoader());
return in.readObject();
I do not like this solution. I must be able to resolve this within the
means provided by Eclipse framework, without resorting to method overrides.
Any suggestions?
Thanks,
Alex Molochnikov
Kelman Technologies Inc.
Note: the plugin B that defines DataBucket exports its package via the
Export-Package manifest header, and the plugin A that does the
serialization declares plugin B in its Require-Bundle header. However,
this does not make this class accessible to the class loader when it is
invoked by the standard ObjectInputStream.
|
|
| |
| Re: [De]serialization of objects in plugin [message #331753 is a reply to message #331747] |
Fri, 19 September 2008 15:45  |
| Eclipse User |
|
|
|
Originally posted by: alexm.xxx.yyy
Thanks, Paul.
I was hoping that it was just me missing something obvious. And I am
somewhat surprised that Eclipse framework essentially strips off the
ability to serialize (and later deserialize) an object using standard
Java mechanisms.
Alex Molochnikov
Paul Webster wrote:
> This is a not so easy problem in eclipse. In the platform they use
> org.eclipse.ui.IElementFactory for saving and restoring contributed
> object state. i.e. the platform forces each plugin that provides a
> persistable object to provide a factory to recreate it (this getting
> around the classloading problem).
>
> The other option would be to save the bundle id along with each object,
> and then when re-creating you can get the Bundle and ask it to load the
> class using org.osgi.framework.Bundle.loadClass(String)
>
> The first pattern requires contributing bundles to opt-in to serialize
> requests and the second pattern would probably require you to continue
> to modify the ObjectInputStream.
>
> PW
>
|
|
| |
| Re: [De]serialization of objects in plugin [message #331761 is a reply to message #331756] |
Sat, 20 September 2008 00:51 |
| Eclipse User |
|
|
|
Originally posted by: alexm.xxx.yyy
Paul Webster wrote:
>...
> It doesn't, at least not any more than any container provider (think
> JEE). If you can see an upstream plugin, you can serialized those
> objects. In your example, if A requires plugin B, then it's not problem.
>...
For a moment I thought that I understood the problem. Now I am confused.
My plugin A does require plugin B. It is listed in the plugin A's
manifest (in Require-Bundle header). Yet, when A attempts to deserialize
an object from one of B's classes, the exception is thrown.
Scratching my head...
Alex Molochnikov
|
|
|
| Re: [De]serialization of objects in plugin [message #331762 is a reply to message #331761] |
Sat, 20 September 2008 01:14 |
 Ed Merks
Messages: 33183
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060205040803020400000103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
I suspect the problem you described is the opposite of the actual
problem. You might find that adding this to the MANIFEST.MF of the base
plugin will help:
Eclipse-BuddyPolicy: dependent
I added this to EMF's Ecore plugin so that the Ecore plugin itself is
able to serialize and deserialize objects from any plugin that depends
on Ecore.
Eclipse-BuddyPolicy: dependent
Alex Molochnikov wrote:
> Paul Webster wrote:
>> ...
>> It doesn't, at least not any more than any container provider (think
>> JEE). If you can see an upstream plugin, you can serialized those
>> objects. In your example, if A requires plugin B, then it's not
>> problem.
>> ...
>
> For a moment I thought that I understood the problem. Now I am confused.
>
> My plugin A does require plugin B. It is listed in the plugin A's
> manifest (in Require-Bundle header). Yet, when A attempts to
> deserialize an object from one of B's classes, the exception is thrown.
>
> Scratching my head...
>
> Alex Molochnikov
--------------060205040803020400000103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
I suspect the problem you described is the opposite of the actual
problem. You might find that adding this to the MANIFEST.MF of the base
plugin will help:<br>
<blockquote>Eclipse-BuddyPolicy: dependent<br>
</blockquote>
I added this to EMF's Ecore plugin so that the Ecore plugin itself is
able to serialize and deserialize objects from any plugin that depends
on Ecore.<br>
<br>
<br>
Eclipse-BuddyPolicy: dependent<br>
<br>
Alex Molochnikov wrote:
<blockquote cite="mid:gb1hdk$46e$1@build.eclipse.org" type="cite">Paul
Webster wrote:
<br>
<blockquote type="cite">...
<br>
It doesn't, at least not any more than any container provider (think
JEE). If you can see an upstream plugin, you can serialized those
objects. In your example, if A requires plugin B, then it's not
problem.
<br>
....
<br>
</blockquote>
<br>
For a moment I thought that I understood the problem. Now I am
confused.
<br>
<br>
My plugin A does require plugin B. It is listed in the plugin A's
manifest (in Require-Bundle header). Yet, when A attempts to
deserialize an object from one of B's classes, the exception is thrown.
<br>
<br>
Scratching my head...
<br>
<br>
Alex Molochnikov
<br>
</blockquote>
</body>
</html>
--------------060205040803020400000103--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [De]serialization of objects in plugin [message #331763 is a reply to message #331762] |
Sat, 20 September 2008 02:26 |
| Eclipse User |
|
|
|
Originally posted by: NOBODY.NOSPAM.COM
This is a multi-part message in MIME format.
------=_NextPart_000_0046_01C91A95.F36B6200
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
Thank you for the advice. I set up my plugin A manifest like this:
Eclipse-ResgisterBuddy: B
In plugin B's manifest I have:
Eclipse-BuddyPolicy: dependent
No luck.
Alex
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gb1iql$sd5$2@build.eclipse.org...
Alex,
I suspect the problem you described is the opposite of the actual =
problem. You might find that adding this to the MANIFEST.MF of the base =
plugin will help:
Eclipse-BuddyPolicy: dependent
I added this to EMF's Ecore plugin so that the Ecore plugin itself is =
able to serialize and deserialize objects from any plugin that depends =
on Ecore.
Eclipse-BuddyPolicy: dependent
------=_NextPart_000_0046_01C91A95.F36B6200
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thank you for the advice. I set up my =
plugin A=20
manifest like this:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Eclipse-ResgisterBuddy: B</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>In plugin B's manifest I =
have:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Eclipse-BuddyPolicy: =
dependent</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>No luck.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Alex</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gb1iql$sd5$2@build.eclipse.org">news:gb1iql$sd5$2@build.ecli=
pse.org</A>...</DIV>Alex,<BR><BR>I=20
suspect the problem you described is the opposite of the actual =
problem. You=20
might find that adding this to the MANIFEST.MF of the base plugin will =
help:<BR>
<BLOCKQUOTE>Eclipse-BuddyPolicy: dependent<BR></BLOCKQUOTE>I added =
this to=20
EMF's Ecore plugin so that the Ecore plugin itself is able to =
serialize and=20
deserialize objects from any plugin that depends on=20
Ecore.<BR><BR><BR>Eclipse-BuddyPolicy: =
dependent</BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0046_01C91A95.F36B6200--
|
|
|
| Re: [De]serialization of objects in plugin [message #331764 is a reply to message #331763] |
Sat, 20 September 2008 04:01 |
Ed Merks
Messages: 33183
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040103020903060900060508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
I suspect there's something going on you've left out. If plugin A
depends on plugin B, it should be able to load the classes from plugin
B, as Paul already suggested... Can you reproduce this problem with a
simple test case you could share?
Alex Molochnikov wrote:
> Ed,
>
> Thank you for the advice. I set up my plugin A manifest like this:
>
> Eclipse-ResgisterBuddy: B
>
> In plugin B's manifest I have:
>
> Eclipse-BuddyPolicy: dependent
>
> No luck.
>
> Alex
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote
> in message news:gb1iql$sd5$2@build.eclipse.org...
> Alex,
>
> I suspect the problem you described is the opposite of the actual
> problem. You might find that adding this to the MANIFEST.MF of the
> base plugin will help:
>
> Eclipse-BuddyPolicy: dependent
>
> I added this to EMF's Ecore plugin so that the Ecore plugin itself
> is able to serialize and deserialize objects from any plugin that
> depends on Ecore.
>
>
> Eclipse-BuddyPolicy: dependent
>
--------------040103020903060900060508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
I suspect there's something going on you've left out. If plugin A
depends on plugin B, it should be able to load the classes from plugin
B, as Paul already suggested... Can you reproduce this problem with a
simple test case you could share?<br>
<br>
<br>
Alex Molochnikov wrote:
<blockquote cite="mid:gb1n01$3nl$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2737.800" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Ed,</font></div>
<div> </div>
<div><font face="Arial" size="2">Thank you for the advice. I set up
my plugin A manifest like this:</font></div>
<div> </div>
<div><font face="Arial" size="2">Eclipse-ResgisterBuddy: B</font></div>
<div> </div>
<div><font face="Arial" size="2">In plugin B's manifest I have:</font></div>
<div> </div>
<div><font face="Arial" size="2">Eclipse-BuddyPolicy: dependent</font></div>
<div> </div>
<div><font face="Arial" size="2">No luck.</font></div>
<div> </div>
<div><font face="Arial" size="2">Alex</font></div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:gb1iql$sd5$2@build.eclipse.org">news:gb1iql$sd5$2@build.eclipse.org</a>...</div>
Alex,<br>
<br>
I suspect the problem you described is the opposite of the actual
problem. You might find that adding this to the MANIFEST.MF of the base
plugin will help:<br>
<blockquote>Eclipse-BuddyPolicy: dependent<br>
</blockquote>
I added this to EMF's Ecore plugin so that the Ecore plugin itself is
able to serialize and deserialize objects from any plugin that depends
on Ecore.<br>
<br>
<br>
Eclipse-BuddyPolicy: dependent</blockquote>
</blockquote>
</body>
</html>
--------------040103020903060900060508--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [De]serialization of objects in plugin [message #331765 is a reply to message #331764] |
Sat, 20 September 2008 04:43 |
| Eclipse User |
|
|
|
Originally posted by: NOBODY.NOSPAM.COM
This is a multi-part message in MIME format.
------=_NextPart_000_0063_01C91AA9.191C2580
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
I will try putting together a small test case on Sunday.
Thanks,
Alex
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gb1si5$5vb$1@build.eclipse.org...
Alex,
I suspect there's something going on you've left out. If plugin A =
depends on plugin B, it should be able to load the classes from plugin =
B, as Paul already suggested... Can you reproduce this problem with a =
simple test case you could share?
------=_NextPart_000_0063_01C91AA9.191C2580
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2737.800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will try putting together a small =
test case on=20
Sunday.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Alex</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gb1si5$5vb$1@build.eclipse.org">news:gb1si5$5vb$1@build.ecli=
pse.org</A>...</DIV>Alex,<BR><BR>I=20
suspect there's something going on you've left out. If plugin A =
depends=20
on plugin B, it should be able to load the classes from plugin B, as =
Paul=20
already suggested... Can you reproduce this problem with a =
simple test=20
case you could share?</BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0063_01C91AA9.191C2580--
|
|
|
| Re: [De]serialization of objects in plugin [message #331767 is a reply to message #331764] |
Sat, 20 September 2008 17:38 |
| Eclipse User |
|
|
|
Originally posted by: alexm.xxx.yyy
This is a multi-part message in MIME format.
--------------020305040408070804050304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
I've put together a small test case that demonstrates the problem.
The serializable class is in com.kelman.serialization plugin (referred
to as plugin B in my previous posts). It is just an empty class
(DataBucket) that extends Object, implements Serializable interface, and
adds no instance vars.
The com.kelman.serialization.test plugin (a.k.a. plugin A) is a JUnit
test that has two classes:
Serializer - serializes DataBucket and saves it in a file
(C:/tmp/serialization.test).
Deserializer - attempts to read the file into a byte buffer and
deserialize it into the DataBucket object.
When Deserializer is run as a plain JUnit test, it works. When the same
test is run as JUnit PLug-in test, it throws the ClassNotFoundException.
Please have a look at the MANIFEST.MF files in both plugins to spot any
irregularities.
Thank you very much for your help.
Alex Molochnikov
Ed Merks wrote:
> Alex,
>
> I suspect there's something going on you've left out. If plugin A
> depends on plugin B, it should be able to load the classes from plugin
> B, as Paul already suggested... Can you reproduce this problem with a
> simple test case you could share?
--------------020305040408070804050304
Content-Type: application/octet-stream;
name="com.kelman.serialization.jar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="com.kelman.serialization.jar"
UEsDBBQACAAIAF1YNDkAAAAAAAAAAAAAAAAtAAQAc3JjL2NvbS9rZWxtYW4v Y3Jvc3NwbG90
L0Nyb3NzcGxvdFBsdWdpbi5qYXZh/soAAJWRTWrDMBCF1zb4DsKrJAvlAKYQ 2nTRVUtT6FqV
J84QWRIzUhJacvfKcZy/UmhBSEjMfO/Nk1d6rRoQ2rVyDaZVVmpyzN64UBV5 kWPrHQXhqJGg
DXoGqR2BpGgDtiBfTGzQVleFjhuUS1ItbB2t5X20tYEHZwPseuhsEb0nYH5X ZNE2PCqt4XJc
5D5+GNRCG8UsHgYnvYhI7WBrFsfrV5Fnx3oOKqRjiVYZsQiUmOJpLu5EeTEY A6Ey+JlKnS2r
rptwowIM7bd6fpgtS2s6maRdTMTbqovLcqCog6PD4/Rs5QYyGh98Zj0rOQor 5A6574LIZs8b
IMIazoCNw7pzRGF0lVwn2p3jhCC3ZfG40+C7WXoFjh5I9o1D6V+EnP+fzmkS G42pLpUT6afw
KbdXCJEsJ2oKfKUIaoEpRWU13Gb4y380EOawVNGEIVU6MC8+KmnuvwFQSwcI 11IMC1QBAADU
AgAAUEsDBBQACAAIAEtYNDkAAAAAAAAAAAAAAAA1AAAAc3JjL2NvbS9rZWxt YW4vY3Jvc3Nw
bG90L3NwYXRpYWxpbmRleC9EYXRhQnVja2V0LmphdmF1k01PwzAMhu+T9h98 3C5BnNEu40tI
SDsMuCAOXua22dwkSryxgfbfSbtCwwa5NLX95n3sph71GksC7Wq1Jq7RKh1c jJ6dqOhRDLKx
S9pdDQfDgam9CwIr3KIyTj3MbneavBhnr86ScwqN9gMXTCdZm9LTvdB0UxQU /kjqCq0ljurO
MF0fX3IAF0qFHnVFKoHXzkbFaMves0F6FsOxVfnNgo0GzRgj3KDgdKPXJJBO Y6rJSoScFj6H
A0jLB7NFIYiSztNQGIsM7GwJsa1+oRAbn4cbmMDlY2vV6o52W2eWXaX5oFHW CnT9jb+dmnVx
AfeJSSrqRUtwixVpgWWCBoRFGhpgCLjvdU3s9S3TzI6SCZxPQ/U4Upk4/kHu AOa4pZagNwJj
20iR8Pva/uu1pd12ksUVMjudxjc6JVNMtpSqMc976GR+I2eKf0oLNn6U5yTs 84k2q5u0eg8m
ofTiXHaAxKkrGGX3GWh8ehSpdCGszCX9Mk8BNf3yPhy36XH4AlBLBwghQOxY fwEAAFQDAABQ
SwMEFAAIAAgAeHRnNgAAAAAAAAAAAAAAAAoAAAAuY2xhc3NwYXRonY89C8Iw FEVnBf9DyG6q
m0NrEamgQ5VSZ6nJo43Gl5gP0X9vVYouOri9ezmcy4vT60mRC1gnNSZ0zEaU AHItJNYJ3ZaL
4YSm00E/5qpyzlS+aUPvnQC9vZGjRJFQZzklj/J1Rt9JrrEjta0ZcCWNA3YQ nqkqIG/adbYq
st18nZezZZ4Vf9iMAMa1BWbhHKQFsVGhluh+qXTwJvjOtpf4hOPo8/s7UEsH CNUcnNKlAAAA
MwEAAFBLAwQUAAgACACGQpc2AAAAAAAAAAAAAAAACgAAAC5jdnNpZ25vcmUV ysEJwCAQRNH7
wDTiwRpSi7qEJcaVVXNM7TGnx4cfXiLElK+faieRltay0UZkcyGKjklUTYRL N98R110D8YgP
tRa7WxefKoM4iu3hA1BLBwi/wAI/TQAAAFgAAABQSwMEFAAIAAgAyWQDNwAA AAAAAAAAAAAA
AAgAAAAub3B0aW9uc0vOz9XLTs3JTczTSy7KLy4uyMkv0U9JTSpNV7BVSEvM KU7l5UrGqUY/
JbEkMSmxONU5P6+kKDOptCQzPw+hEQBQSwcIk4pJNEAAAABdAAAAUEsDBBQA CAAIABhUNDkA
AAAAAAAAAAAAAAAIAAAALnByb2plY3S9ksFOBCEQRM+a+A+buQt688DOJrrZ m8Zk9QNaaEdW
aAgwG+PXC8hoJhMTD8ZbV1HFI4DYvFmzOmKI2tG6u2QX3QpJOqVpWHePD7vz q27Tn50KH9wB
ZdpilEH7lNPZPREEFnvpLHtFY4FYxKDB6HcoCcHrcsnliEVKveDTVNy2aayC z9TTqI3ae5RF
NXmTq0CqOg3twsBQGu0jsoNKTLqQBzhCLWD4PkJuQBjGwo5N87kh+ILyK65X yG6B9DPGdP2/
2L18QQt/Am3OdOWZl8aALf0pFvh7Mw6a7upiodfQT4XZ89CiM82F+PUX5t/t A1BLBwhyOBjm
7wAAAK0CAABQSwMEFAAIAAgAclk0OQAAAAAAAAAAAAAAABQAAABNRVRBLUlO Ri9NQU5JRkVT
VC5NRnWQQU7DMBBF95FyBx+AWMDSiAVFXSBaFFHU/WAPqVV7xtgOanp6kqaY smD9/v96M2sg
+4EpN1uMyTIpcSOv62rRk3HYrM+0wNuCXsCjEo+RUwqOs2hd3zWWCt8M/p2d 1XNOs5d7dB5I
JowWnD1CHhfvkqXOYR6373PssdQvdS6EHnS2X5A5/pnUPxay+Ew6FzZbJDOV nk8F8YZ6R+y4
s5jEE2lZgivWRU6JcF55xc/eRmzmkBIcO4na2ZBQao4oY0/ZeryqqxODAHo3 Ie+ZknRAXV0t
50KzguOwyRCzEvPJy0PgmJsW9B46/OeyFEanUY0MHn63Fr0xQzv9eVDCYBjP RMp19Q1QSwcI
pLboDwYBAADXAQAAUEsDBBQACAAIAIdUNDkAAAAAAAAAAAAAAAAQAAAAYnVp bGQucHJvcGVy
dGllc8svLSkoLdHTU7BVSMrM0+flApJ6mXnJOaUpqcVAwYKc0nSgSEVujk4M L5cCKvB1DXHU
9fRz08ciV5yckZqbiE1GD4sYyO7k/Fz97NSc3EQgsyi/uLggJ79Ev7ggsSQz MSczLyW1Apth
ODXychXnlxYlp4K9VlyUDBQAAFBLBwjyW6UuewAAAOwAAABQSwMEFAAIAAgA yWQDNwAAAAAA
AAAAAAAAABEAAABwbHVnaW4ucHJvcGVydGllcwMAUEsHCAAAAAACAAAAAAAA AFBLAwQUAAgA
CABIUzQ5AAAAAAAAAAAAAAAACgAAAHBsdWdpbi54bWyzsa/IzVEoSy0qzszP s1Uy1DNQUkjN
S85PycxLt1UKDXHTtVCyt+PlsrFPTc7JLChORag11jOCSBXklKZn5tlx2ehD WbxcAFBLBwhX
CPDzRwAAAFcAAABQSwECFAAUAAgACABdWDQ511IMC1QBAADUAgAALQAEAAAA AAAAAAAAAAAA
AAAAc3JjL2NvbS9rZWxtYW4vY3Jvc3NwbG90L0Nyb3NzcGxvdFBsdWdpbi5q YXZh/soAAFBL
AQIUABQACAAIAEtYNDkhQOxYfwEAAFQDAAA1AAAAAAAAAAAAAAAAALMBAABz cmMvY29tL2tl
bG1hbi9jcm9zc3Bsb3Qvc3BhdGlhbGluZGV4L0RhdGFCdWNrZXQuamF2YVBL AQIUABQACAAI
AHh0ZzbVHJzSpQAAADMBAAAKAAAAAAAAAAAAAAAAAJUDAAAuY2xhc3NwYXRo UEsBAhQAFAAI
AAgAhkKXNr/AAj9NAAAAWAAAAAoAAAAAAAAAAAAAAAAAcgQAAC5jdnNpZ25v cmVQSwECFAAU
AAgACADJZAM3k4pJNEAAAABdAAAACAAAAAAAAAAAAAAAAAD3BAAALm9wdGlv bnNQSwECFAAU
AAgACAAYVDQ5cjgY5u8AAACtAgAACAAAAAAAAAAAAAAAAABtBQAALnByb2pl Y3RQSwECFAAU
AAgACAByWTQ5pLboDwYBAADXAQAAFAAAAAAAAAAAAAAAAACSBgAATUVUQS1J TkYvTUFOSUZF
U1QuTUZQSwECFAAUAAgACACHVDQ58lulLnsAAADsAAAAEAAAAAAAAAAAAAAA AADaBwAAYnVp
bGQucHJvcGVydGllc1BLAQIUABQACAAIAMlkAzcAAAAAAgAAAAAAAAARAAAA AAAAAAAAAAAA
AJMIAABwbHVnaW4ucHJvcGVydGllc1BLAQIUABQACAAIAEhTNDlXCPDzRwAA AFcAAAAKAAAA
AAAAAAAAAAAAANQIAABwbHVnaW4ueG1sUEsFBgAAAAAKAAoAlQIAAFMJAAAA AA==
--------------020305040408070804050304
Content-Type: application/octet-stream;
name="com.kelman.serialization.test.jar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="com.kelman.serialization.test.jar"
UEsDBBQACAAIACRUNDkAAAAAAAAAAAAAAAAIAAQALnByb2plY3T+ygAAvZJB T8QgEIXPmvgf
Nr0LevPAdhPd7E1jsvoDRhgrKwwE6Mb46wWkmqYx8WC8zXu814+2IzZv1qyO GKJ2tO4u2UW3
QpJOaRrW3ePD7vyq2/Rnp8IHd0CZthhl0D7ldHZPBIHFXjrLXtFYIBYxaDD6 HUqCJYxJ8Jop
4ZyzSKkXfJqK254cq+Az9TRqo/YeZVFN3uQqkKpO47swMJRG+4jsoBKTLuQB jlALGL6vkBsQ
hrGwY9N8bgi+oPyK6xWyWyD9nF/5+n+xe/mCFv4E2pzpk2deGgO29KdY4O/N OGi6q4eFXkM/
FWa/hxadaS7Er12Y79wHUEsHCCeHbSnzAAAAsgIAAFBLAwQUAAgACACLWDQ5 AAAAAAAAAAAA
AAAAFAAAAE1FVEEtSU5GL01BTklGRVNULk1GdY69TgMxDMf3SHmHPACJgPHG SgwIFaEWdU9z
vqshsa9xMpSnJ+XoqUh0tH//r7UnHECK3UEWZOrMg7vXalWpj2DXv3SBjwt6 9Qk6896gmLdY
R4u0sO0p7TlimDWBk/uEmDw5gYw+4pcvLc2Vs3kxXQ+4mrAD6jl35uUnoRWG A3HkEUHMMwWn
1QaOFTPY2XC7704rw3l0fvLhAK7JEpO46Gm8oI9KWC4HhIiTnIUZ3IAR9nUY 2sh/eQbhmgPc
oJUKJtDqaf7aDYwoBfKq9v3pz+SQWWSKXLT6BlBLBwjOp7YF2QAAAJwBAABQ SwMEFAAIAAgA
6Vk0OQAAAAAAAAAAAAAAAC0AAABzcmMvY29tL2tlbG1hbi9jcm9zc3Bsb3Qv c2kvRGVzZXJp
YWxpemVyLmphdmF1VM2OmzAQvkfKO4w4gVp5741WapNtTz1UZaseqj1MzIS4 MTayh02yVd69
QyCFkNQXw/j7mRkP1Kh3WBJoX6kd2Qqd0sHHWFvPKprFfDafmar2gf8DqZEN WuMKOqgnZFw2
ekc85v3GV1TGq+/oCl990ppi/GIsLa4RTiDLI9Oy2Wwo3DnUW3SObFQtedW9 XPk0zrDaBKxo
78NOPVPkFUYaY3woFdaot6SknMq7qCy6UuUU2irepBjvfrCx8cz6mDd1HSTf nxiccWVME2dj
ks1ndbO2RoO2GCM8Uez5FIAOTK6IcLGHP60SyOo5r94UwHL6jcLGB+mnpjRr YdCvnIOYAWMo
idtq4RGS1YcHruqHOM5UtTLJYmAOT9NuQ8C+6RcEh+PYtF0dRtwc7W8U0iGf 95CEfZItrtmj
e4H+skSq01TC7M/SKc84hkJG5yu5krdCSSWSXSRkCt/ohjNMCqy77XEUU2it 18iUDrpThYt8
ICzSTmMK6aKC2Mt836SwFrtfL+fM+46dI4Pjy3056cQ5rane8PUI8rxJJ4Zg BrdDqoph8u5q
5sfIVCnfsKplpti6NPknnsC73mlMO4E0Tm8h/XzQVLdWQNl0UKiTy1l+H88B 9fUFnbpH2U5/
AVBLBwiZ8NLQ3AEAAGAEAABQSwMEFAAIAAgAqFg0OQAAAAAAAAAAAAAAACsA AABzcmMvY29t
L2tlbG1hbi9jcm9zc3Bsb3Qvc2kvU2VyaWFsaXplci5qYXZhdZPNTsMwDIDv k/YOVk+dhLI7
0yRgwAPQSZy91GxhaRIl3g+gvTvJ2rKsQC5J08+fHad1KLe4JpC2EVvSDRoh vQ3BacsiqNl4
NB6pxlnP/yAOWaFWpqajeETGh53cEudx77hHoax4Vppmv3Zf0NS2uZeSQviD MBGRGzSGdDgb
Fu3DVYKdUSzePDZ0sH4rlhR4gYHOzF21c85H+St6o8w6lIXRoZiMR2630kqC 1BgCVOTTMT7J
Ax2ZTB2g18BX8kAczqs9MkHFPpqA0a+Ju6I7onXuraqBY3yvjU2yppwkFXTj Eg1zKBa3U27c
NOS8SIZidgm59BdW7TQHQ4dsv5xk+NkdcE91lyWxaVlecuf88CrAY9VHZxj7 j/wcaWRgl2bo
Kn/quIHCH4o8b19rd7Xnkvv1PHeLWHT3ohwK2oaIvoFtwg4esrlSahvoynYC iSw3UD4dJbl0
EUCT4YlJxI/BcMXx/1l6lEmRv8907TJOp29QSwcIDdEt3XABAABtAwAAUEsD BBQACAAIALRN
MjkAAAAAAAAAAAAAAAAQAAAAYnVpbGQucHJvcGVydGllc8svLSkoLdHTU7BV SMrM0+flApJ6
mXnJOaUpqcVAQV/XEEddTz83fZ0YXi4FVFBclKyfnJ+rn52ak5uYp59clF9c XJCTX6JfnIlN
uR4vV3F+aVFyKtg2kGZeLgBQSwcIEAOzm1sAAAB/AAAAUEsDBBQACAAIAABs EzkAAAAAAAAA
AAAAAAAKAAAALmNsYXNzcGF0aJ2QTWsCMRCGzxX6H0LuJvbmYbeiolAPKmLP JZ0Ma9zszJoP
0X/v2kXaQ+mht3nheZ8XpphcGi/OGKJjKuWLGkmBBGwdVaV83y+HYzl5fR4U 4E2MrUmHLjx9
J6QUrgIv4HNfAW50jb4xpCFwB3lO2rGeZagxqaM5GylqR7aUMYAUd0l/6t/M PQlMD5JDpRC8
ayOqo03Km0xw6KbVarf4mG/W++nberH7h621qIADqoCn7ALarc+Vo/iXinNq c3rYPh19wYX+
+a0bUEsHCCY7+/LIAAAAYwEAAFBLAQIUABQACAAIACRUNDknh20p8wAAALIC AAAIAAQAAAAA
AAAAAAAAAAAAAAAucHJvamVjdP7KAABQSwECFAAUAAgACACLWDQ5zqe2BdkA AACcAQAAFAAA
AAAAAAAAAAAAAAAtAQAATUVUQS1JTkYvTUFOSUZFU1QuTUZQSwECFAAUAAgA CADpWTQ5mfDS
0NwBAABgBAAALQAAAAAAAAAAAAAAAABIAgAAc3JjL2NvbS9rZWxtYW4vY3Jv c3NwbG90L3Np
L0Rlc2VyaWFsaXplci5qYXZhUEsBAhQAFAAIAAgAqFg0OQ3RLd1wAQAAbQMA ACsAAAAAAAAA
AAAAAAAAfwQAAHNyYy9jb20va2VsbWFuL2Nyb3NzcGxvdC9zaS9TZXJpYWxp emVyLmphdmFQ
SwECFAAUAAgACAC0TTI5EAOzm1sAAAB/AAAAEAAAAAAAAAAAAAAAAABIBgAA YnVpbGQucHJv
cGVydGllc1BLAQIUABQACAAIAABsEzkmO/vyyAAAAGMBAAAKAAAAAAAAAAAA AAAAAOEGAAAu
Y2xhc3NwYXRoUEsFBgAAAAAGAAYApgEAAOEHAAAAAA==
--------------020305040408070804050304--
|
|
| |
| Re: [De]serialization of objects in plugin [message #331769 is a reply to message #331767] |
Sat, 20 September 2008 23:15 |
Ed Merks
Messages: 33183
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010203010701070004030200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
Adding this to
Eclipse-BuddyPolicy: dependent
the org.apache.commons.lang plugin solved the problem. The
SerializationUtils class seems kind of useless in the context of Eclipse
class loading without some type of buddy loading schema. I'm not sure
with whom to take up an issue like this. The path of least resistance
is to just use this instead of the utility commons utility:
ObjectInputStream inputStream = new ObjectInputStream(new
ByteArrayInputStream(data));
DataBucket bucket = (DataBucket)inputStream.readObject();
You wouldn't even need the buddy stuff in this case, since the second
plugin where you do this can already load all the classes.
Alex Molochnikov wrote:
> Ed,
>
> I've put together a small test case that demonstrates the problem.
>
> The serializable class is in com.kelman.serialization plugin (referred
> to as plugin B in my previous posts). It is just an empty class
> (DataBucket) that extends Object, implements Serializable interface,
> and adds no instance vars.
>
> The com.kelman.serialization.test plugin (a.k.a. plugin A) is a JUnit
> test that has two classes:
>
> Serializer - serializes DataBucket and saves it in a file
> (C:/tmp/serialization.test).
>
> Deserializer - attempts to read the file into a byte buffer and
> deserialize it into the DataBucket object.
>
> When Deserializer is run as a plain JUnit test, it works. When the
> same test is run as JUnit PLug-in test, it throws the
> ClassNotFoundException.
>
> Please have a look at the MANIFEST.MF files in both plugins to spot
> any irregularities.
>
> Thank you very much for your help.
>
> Alex Molochnikov
>
>
> Ed Merks wrote:
>> Alex,
>>
>> I suspect there's something going on you've left out. If plugin A
>> depends on plugin B, it should be able to load the classes from
>> plugin B, as Paul already suggested... Can you reproduce this
>> problem with a simple test case you could share?
--------------010203010701070004030200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Adding this to <br>
<blockquote>Eclipse-BuddyPolicy: dependent<br>
</blockquote>
the org.apache.commons.lang plugin solved the problem. The
SerializationUtils class seems kind of useless in the context of
Eclipse class loading without some type of buddy loading schema. I'm
not sure with whom to take up an issue like this. The path of least
resistance is to just use this instead of the utility commons utility:<br>
<br>
ObjectInputStream inputStream = new ObjectInputStream(new
ByteArrayInputStream(data));<br>
DataBucket bucket = (DataBucket)inputStream.readObject();<br>
<br>
You wouldn't even need the buddy stuff in this case, since the second
plugin where you do this can already load all the classes.<br>
<br>
<br>
Alex Molochnikov wrote:
<blockquote cite="mid:gb3ceh$prh$1@build.eclipse.org" type="cite">Ed,
<br>
<br>
I've put together a small test case that demonstrates the problem.
<br>
<br>
The serializable class is in com.kelman.serialization plugin (referred
to as plugin B in my previous posts). It is just an empty class
(DataBucket) that extends Object, implements Serializable interface,
and adds no instance vars.
<br>
<br>
The com.kelman.serialization.test plugin (a.k.a. plugin A) is a JUnit
test that has two classes:
<br>
<br>
Serializer - serializes DataBucket and saves it in a file
(C:/tmp/serialization.test).
<br>
<br>
Deserializer - attempts to read the file into a byte buffer and
deserialize it into the DataBucket object.
<br>
<br>
When Deserializer is run as a plain JUnit test, it works. When the same
test is run as JUnit PLug-in test, it throws the
ClassNotFoundException.
<br>
<br>
Please have a look at the MANIFEST.MF files in both plugins to spot any
irregularities.
<br>
<br>
Thank you very much for your help.
<br>
<br>
Alex Molochnikov
<br>
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Alex,
<br>
<br>
I suspect there's something going on you've left out. If plugin A
depends on plugin B, it should be able to load the classes from plugin
B, as Paul already suggested... Can you reproduce this problem with a
simple test case you could share?
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------010203010701070004030200--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [De]serialization of objects in plugin [message #331770 is a reply to message #331769] |
Sun, 21 September 2008 17:15 |
| Eclipse User |
|
|
|
Originally posted by: alexm.xxx.yyy
Ed Merks wrote:
> Alex,
>
> Adding this to
>
> Eclipse-BuddyPolicy: dependent
>
> the org.apache.commons.lang plugin solved the problem. The
> SerializationUtils class seems kind of useless in the context of Eclipse
> class loading without some type of buddy loading schema. I'm not sure
> with whom to take up an issue like this.
OK, I finally got it. Any object that gets [de]serialized must not have
dependency on the third-party plugins unless those plugins set the buddy
policy to "dependent".
This can be a show-stopper, for the lack of control over those plugins.
And even if modifying MANIFEST.MF is possible in the local copy of the
plugin (as in the case with Apache plugins), it would be undesirable
from the maintenance POV.
I ended up making a partial copy of SerializableUtils source, and
included it into my plugin.
Thank you very much for your help.
Alex
|
|
|
| Re: [De]serialization of objects in plugin [message #331771 is a reply to message #331770] |
Sun, 21 September 2008 17:45 |
Ed Merks
Messages: 33183
Registered: July 2009 |
Senior Member |
|
|
Alex,
Comments below.
Alex Molochnikov wrote:
> Ed Merks wrote:
>> Alex,
>>
>> Adding this to
>>
>> Eclipse-BuddyPolicy: dependent
>>
>> the org.apache.commons.lang plugin solved the problem. The
>> SerializationUtils class seems kind of useless in the context of
>> Eclipse class loading without some type of buddy loading schema. I'm
>> not sure with whom to take up an issue like this.
>
> OK, I finally got it. Any object that gets [de]serialized must not
> have dependency on the third-party plugins unless those plugins set
> the buddy policy to "dependent".
No, that's not a good characterization of the problem. The problem is
as follows, as far as I understand it... The class loader used by the
underlying Java deserialization utilities seems to depend on the class
loader of the caller to the object stream's methods. So if you have a
utility method in SerializationUtils then the library in which the
SerializationUtils class itself appears needs to be able to see/load the
classes being loaded by the Java frameworks (and can't). But if you
copy that same deserialization code into a different library, as I did
by directly doing these same steps in the test class, then the class
loader for that library is used. That's why it works the way I wrote
it, the test plugin's class loader is used, but not by calling the
utility method in the framework library, which has a class loader that
doesn't see your plugins without some type of buddy policy.
>
> This can be a show-stopper, for the lack of control over those plugins.
If the libraries do need to do such things directly, in this case it's
just a utility class that you don't really need to use, then they really
do need to set up some type of buddy policy to be properly enabled. I
suggest you consider opening an Orbit bugzilla to draw attention to this
issue. If you do take the time (the issue will never be addressed if
you don't), please post the bugzilla number here.
> And even if modifying MANIFEST.MF is possible in the local copy of the
> plugin (as in the case with Apache plugins), it would be undesirable
> from the maintenance POV.
I agree. Though I think the value of the utility you're using is so
minimal as to be negligible, but it's still an issue worth raising.
>
> I ended up making a partial copy of SerializableUtils source, and
> included it into my plugin.
That's seems a good approach.
>
> Thank you very much for your help.
You're welcome.
>
> Alex
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Jul 18 02:27:05 GMT 2024
Powered by FUDForum. Page generated in 0.05167 seconds |
] 
Search
Help
Register
Login
Home
