Eclipse + XStream

[lumo]

Hallo!

hat einer von euch schon mal versucht xstream in eclipse zu verwenden?

ich habe mehrere plugins laufen (mit osgi services)
und will nun die objekte der services per xstream speichern.

läuft in meinem test (alle interfaces etc in einem kleinen projekt) bestens.

wenn ich jedoch die ganze sache aufsplitte (also die annotations in jedem eigenen plugin drin)
und dann in einem eigenen plugin (osgi service) die objekte in xml umwandle
dann ignoriert er meine annotations.

ich hatte auch schon kontakt mit der NG von XStream, dort meinte man folgendes:

But it is. I am no Eclipse/OSCi programmer, but AFAICS each plugin will use its own class loader i.e. the classes are no longer the same. Can you try this on the context of above:

=============== %< ===================
Site s = service.getDummySite(); // unimportant how i get the Site...
assert SiteImpl.class == s.getClass();
=============== %< ===================

... and it will get worse at deserialization time...

ich habe das mal angetestet und SiteImpl.class == s.getClass() -> true

...was nun?
ich würde mich freuen, falls jemand weiss, woran das liegen kann.

hinweis: ich bekomme keinerlei exceptions!

 

[Wildcard]

Hast du XStream als OSGi Bundle verpackt? Eventuell brauchst du eine Buddy-Policy im Manifest damit das XStream Bundle deine Klassen sehen kann.

 

[lumo]

ich habe folgendes:

mein klassen sind in verschiedenen plug-ins.
die klassen können über ein osgi-service bekommen werden (also ich hole mir zuerst das service und das service ist dann meine factory)

mein xml-generator ist xstream, der auch in einem plug-in und einem osgi-service sitzt.
ich habe die packages, in denen die klassendefinitionen sind im dazugehörigen plug-in exportiert und die visibility auf mein xml-service eingeschränkt.

ist es das was du meinst?
müsste er mir nicht melden, dass er die klassen nicht kennt wenn er sie nicht 'sieht'?

 

[Wildcard]

Da du XStream als Service verwenden willst macht es offensichtlich wenig Sinn das du in diesem Bundle alles importieren musst was du evtl. irgendwann mal als XML serialisieren musst. Dafür ist die Buddy Policy.
Für genaueres schau mal hier:
EclipseZone - Eclipse - a tale of two VMs (and many classloaders)

A larger problem occurs when using libraries that expect to be able to see your code as well as their own. This includes libraries such as log4j and generator tools such as JibX that both supply services and consume code. Because Eclipse uses a partitioned class loading mechanism, the ClassLoader of the org.apache.log4j can't see the classes defined in org.example.myplugin, since it's a separate ClassLoader. As a result, log4j can't use your supplied class for logging, and complains.

This is the purpose of the buddy class loading in Eclipse. It is designed to work around the issues that can be found in this type of problem.

 

[lumo]

also wenn ich das richtig verstanden habe sollte ich nun in meinen manifest.mf files
folgendes reinschreiben

im at...osgi.service.xml.impl manifest:

Eclipse-BuddyPolicy: registered

in den anderen:

Eclipse-RegisterBuddy: at...osgi.service.xml.impl

nur leider tut sich da trotzdem nichts in richtung korrekter...
oder bin ich da noch immer falsch unterwegs?

note: die imports brauch ich trotzdem noch

 

[lumo]

+ habs jetzt auch noch alternativ mit

Eclipse-BuddyPolicy: global

versucht (also in jede MANIFEST.MF diese zeile statt dem registerbuddy.)
mit dem selben resultat...

 

[Wildcard]

Tut mir leid, da ich nie etwas mit XStream am Hut hatte kann ich dir leider nicht mehr dazu sagen.

 

[lumo]

wie kann ich denn testen ob diese BuddyPolicy funktioniert?
- anscheinend sollte der classloader des einen plugins ja dann auch im classloader des anderen suchen...

 

[Wildcard]

Ja, wenn ein Bundle A Buddies erlaubt und du dieses Bundle in B als Buddy einträgst, dann sieht A alle Klassen von B.

 

[lumo]

bräuchte ich dann keine includes mehr definieren?
muss ich bei A dann B nicht mehr als required bundle eintragen?

 

[Wildcard]

A ist die Bibliothek (log4j, XStream). Es macht keinen Sinn das A B überhaupt kennt. Es geht dabei nur um spezielle Bibliotheken die direkt auf Class Objekte von unbekannter Quelle zugreifen.

 

[lumo]

ich hab jetzt eine lösung gefunden, wie sich mein problem auflöst, ohne buddy police.

und zwar muss ich das library in ein eigenes plugin packen, und dann die packages die ich benötige exportieren...

so einfach wärs gewesen... wenn mans gewusst hätte ;(
egal, hab jetzt eine saubere lösung :toll: