| deserialization ClassNotFound when class is supplied through extension-point [message #330816] |
Thu, 14 August 2008 04:33 |
 Paul E. Keyser
Messages: 878
Registered: July 2009 |
Senior Member |
|
|
R3.3, WinXp
We have an extension-point defined in plug-in "com.mun.ist.root"; and
one or more extensions plugged in to that ext.-pt., each of which
supplies a class that implements IThing; the API of IThing includes a
method that returns an IFoo, which is Serializable (for a given IThing
instance there may be many IFoo instances created). One of the IThing's
plugged in is in plug-in "com.mun.ist.leaf" and is called ConcThing,
say; its IFoo is called ConcFoo.
We need for the IFoo's to be Serializable in order to store them between
invocations of our RCP; we do not want to ask all clients who plug in
(and thus define both an IThing and an IFoo) to have also to write a
bunch of XML-specifications in order to be able to write out their IFoo
-- thus we chose (so far) to use Serializable.
Everything is working fine, but when the code attempts to *de*-serialize
a ConcFoo, I get this:
java.lang.ClassNotFoundException: com.mun.ist.leaf.ConcFoo
at java.lang.Class.forName(Class.java:163)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.jav a:599)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream .java:1563)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.ja va:1485)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStre am.java:1718)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1324)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java: 362)
at java.util.HashMap.readObject(HashMap.java:1263)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass .java:1001)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.j ava:1828)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStre am.java:1738)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1324)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStrea m.java:1927)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.j ava:1851)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStre am.java:1738)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1324)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java: 362)
I've read several prior threads on this topic in these newsgroups, which
suggest that:
a) if this were not an extension-point issue, i.e., if there were a
small and fixed number of IFoo implementations, we could solve this with
"Eclipse-RegisterBuddy" -- but that cannot work in our case, since we
would have to have "com.mun.ist.root" know about each and every plug-in
supplying an implementation of IFoo.
b) if we did not care about ClassCastExn (and if I knew how to get a
concrete instance of PackageAdmin), we could extend the
ObjectOutputStream class thus:
class EclipseOutputStream extends ObjectOutputStream {
PackageAdmin pkgAdmin; // initialize it in the constructor
protected void annotateClass(Class clazz) throws IOException {
super.annotateClass(clazz);
Bundle declaringBundle = pkgAdmin.getBundle(clazz);
String bundleName = null;
if (declaringBundle != null) {
bundle = declaringBundle.getSymbolicName();
} else {
bundle = "bootClasspath";
}
this.writeUTF(bundleName);
}
}
c) perhaps there is some other mechanism that Eclipse prefers or would
recommend -- if so, what is that?
thanks,
Paul
|
|
|
Powered by
FUDForum. Page generated in 0.02454 seconds
] 
Search
Help
Register
Login
Home
