Questions & Answers

[mielimonka]

Hallo zusammen,

aktuell habe ich bei einem Webservice Aufruf aus unserem SocialNetworking ContentCreator Modul folgendes Problem:

Wir versuchen Media Inhalte (Bild/Video) aus unserem FS Modul heraus durch einen FirstSpirit Service an einen Webservice zu übergeben, sodass dieser Inhalt dort weiterverarbeitet werden kann.

Hierzu verwenden wir ein DTO("SocialMediaPostDto"), welches einen InputStream des jeweiligen Elements in einem javax.activation.DataHandler Objekt kapselt und an den Webservice (apache cxf) weiterleiten soll.

Beim Aufruf des Services bekomme ich nun folgende Fehlermeldung, da das Objekt nicht serialisiert werden kann:

Parameter not serializable! Method SocialNetworkingContentcreator Service.publishContent(de.espirit.firstspirit.io.ManagerCallSignature@88ac6c7a{manager=SocialNetworkingContentcreator Service, method=publishContent, params=[class de.adesso.socialnetworking.webservice.dto.SocialMediaPostDto, class java.lang.String, class java.lang.String, class java.lang.String]}, [de.adesso.socialnetworking.webservice.dto.SocialMediaPostDto@1a8d06d, 983040, DUMMY, http://localhost:8080/socialnetworking/services/publishing]) - java.io.NotSerializableException: javax.activation.DataHandler

Normale Java Objekte z.B. String können problemlos übertragen werden.

Ich hoffe, jemand kann mir bei dem Problem weiterhelfen oder kennt hierzu best practices / hat eine Idee.

Viele Grüße

Michael

[bIT_sosswald]

Hallo Michael,

ohne das Programm/Modul genau zu kennen, verstehe ich dein Problem so: Du rufst den FS-Service auf und gibst ihm ein Objekt (DTO) mit und dann tritt der genannte Fehler auf?

Soweit ich das aus eigener Erfahrung kenne, kann man einem FS-Service beim Arufruf nur Objekte mitgeben die serialisierbar sind. Ich hatte das Problem z.B. als ich ein "Project"-Objekt an meinen Service übergeben wollte.

Grund für dieses Verhalten ist meines Erachtens, dass der Service auf dem FS-Server läuft, er aber z.B. aus dem SiteArchitect (also von deinem Dekstop-Rechner) über ein Skript aufgerufen werden kann. In einem solchen Fall müssen die Objekte für die Übertragung vom SiteArchitect an den Service serialisiert werden.

Spontan würde ich darauf tippen, dass das DTO nicht serialisierbar ist. Du müsstest also dafür sorgen, dass dieses serialisiert werden kann.

http://docs.oracle.com/javase/6/docs/platform/serialization/spec/serial-arch.html

Eine Alternative ist nur "normale Java Objekte" wie z.B. Strings, also z.B. ID's oder UID's beim Aufruf an den Service zu übergeben und der Service holt sich die benötigten Objekte dann selbst. (Z.B. könnte der Service anhand der übergebenen ID ein Medium aus dem Media-Store holen und dieses dann weiterverarbeiten.)

So habe ich das bei meinem Modul gemacht. Ich übergebe also nur die Project-ID an den Service und dieser ermittelt dann das benötigte Projekt anhand der übergebenen ID.

Evtl. hilft dir das ja schon weiter.

Grüße

Sandro

[mielimonka]

Hi Sandro,

danke für deine schnelle Antwort, leider hilft mir diese noch nicht viel weiter.

Um das Problem noch mal deutlicher zu machen bzw. Missverständnisse auszuräumen:

Das DTO Objekt wird in dem FirstSpirit Service instanziiert und dieser dient dazu einen externen Soap Webservice aufzurufen und diesem das DTO zu übertragen. Hierbei tritt dann das genannte Serialisierungsproblem auf.

Ursprünglich hat dieser Aufruf auch ohne Fehler funktioniert, da sich der FS-Service der den Webservice aufruft im gleichen Projekt befand und alle genutzen .jar Bibliotheken (die apache cxf libraries) in der module.xml auf "scope=server" gestellt waren und somit global zugängig waren.

Nun wurde der FS-Service und sein Interface in eine public und private .jar ausgelagert, sodass wir die scopes auf module stellen konnten und den FirstSpirit Service über sein Interface instanziieren können (über einen ServicesBroker). Seitdem tritt der Fehler mit der Serialisierung auf.

Dem Webservice nur die Project-ID zu übergeben würde größeren Entwicklungsaufwand bedeuten da dieser unabhängig von FirstSpirit laufen soll.

Ich hoffe dass ich das Problem etwas klarer ausgedrückt habe.

Danke und viele Grüße

Michael

[bIT_sosswald]

Hallo Michael,

danke für die Ausführliche Beschreibung.

Ich denke die Ursache des Problems bleibt trotz der anderen Architektur die selbe.

Das DTO bzw. mindestens eines der im Objektgraph des DTO enthaltenen Objekte ist nicht serialisierbar.

Wenn du aus dem FS Service heraus einen externen WebService (der wahrscheinlich irgendwo auf einem Tomcat oder ähnlichem läuft und damit potenziell auch auf einer anderen Maschine) musst du das DTO ja auch zu einem "remote" Service übertragen und damit serialisieren.

Grüße

Sandro

[tenter]

Hallo Michael,

benötigst Du noch weitere Hilfe oder haben Dir Sandros Hinweise bereits geholfen? In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden, wenn sie ähnlichen Problemen gegenüberstehen. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Grüße,

Hannes

[mielimonka · Accepted solution]

Hi,

das Problem habe ich nach einiger Zeit noch behoben bekommen. Das Problem lag nicht daran, dass ein Objekt im Graph nicht serialisierbar war.

Ursprünglich habe ich nur den Webservice Aufruf in dem FS-Service gekapselt und das DTO samt InputStream aus einem nicht FS-Service an den FS-Service übergeben. Hierbei kam es ja zu der genannten Exception.

Nachdem ich den InputStream direkt in dem FS-Service geholt und dort auch das DTO erstellt habe, war das Problem behoben. Anscheinend wird FirstSpirit intern beim aufruf eines Services noch etwas serialisiert, was mir nicht klar war.

Viele Grüße

Michael