In the [3] link in your message the guy has tried this:
xStream.setClassLoader(Thread.currentThread().getContextClassLoader());
Instead he should have tried this
xStream.setClassLoader(getClass().getClassLoader());
The idea is to tell xStream to load classes from your own class loader, aka your
bundle. I am not familiar with XStream but I would guess serialization works
because you pass XStream an Object, it picks up a Class from it and uses
reflection to serialize. On the deserialization pass however XStream has only a
String for the name of the class to deserialize. It can't get that class from
it's own class loader because it does not import it. XStream would have to
import the entire world so it can deserialize any class it meets.
This can be done with the following header in the XStream bundle manifest.
Dynamic-Import: *
This will cause the XStream bundle to import the entire world on demand - it
could work but is a bad idea - all kinds of classes clashing inside the XStream
class space :)
Instead you tell XStream to use your bundle's ClassLoader to resolve String
names to Class objects living inside your bundle. They don't need to even be
exported because XStream uses reflection and only needs a Class object. This
approach will work safely if all deserialized classes are located in one bundle.
If you build object graphs out of classes from many bundles I am afraid you can
have problems. To resolve the issue without importing the world some fancy
classload bridging has to be done. Look here if you fancy the gory details:
http://rinswind.blogspot.com/2009/08/classload-acrobatics-dynamic-code.html
As I said I am not familiar with XStream - I am familiar with the problem as I
understand it. So forgive me if I am completely out of line :)
Cheers,
Todor
Guido Spadotto wrote:
Hi all,
in an OSGi-based project of mine I'm trying to use
XStream to marshall/unmarshall data structures to/from XML.
Saving data to XML is no big issue, but restoring it from XML
throws a CannotResolveClass [1] exception.
I've googled a bit and it seems that XStream requires some
tampering with ClassLoaders [2, 3], which I usually try to avoid, even more
within an OSGi container.
Question 1: Were any of you able to use XStream within an OSGi container
successfully?
Question 2: Do you suggest any other XML marshalling/unmarshalling library
that is more "OSGi-friendly", so to say?
[1]: com.thoughtworks.xstream.mapper.CannotResolveClassException
[2]: http://xstream.codehaus.org/faq.html#Serialization_ClassLoader
[3]: http://osdir.com/ml/java.xstream.user/2008-08/msg00015.html
Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
