Questions & Answers

[novomind]

Hallo.

Wir wollen unsere selbstgeschriebenen Firstspirit-Module auf Maven umstellen.

Gibt es ein Repo, wo ich das fs-client.jar mit entsprechend gut gepflegten transitiven Abhängigkeiten finde?

[andre · Accepted solution]

hi,

kurze antwort - nein

--

andre

[novomind]

Gibt es denn Pläne, dies anzubieten?

[andre]

mir sind keinerlei pläne bekannt fuer alle in der wartung befindlichen firstspirit-version sowas anzubieten. es sollte ja kein problem sein ein "eigenes" lokales/zentrales reprository aufzusetzen.

[novomind]

Sicher nicht, aber die transitiven Abhängigkeiten zu pflegen, die sich ja derzeit scheinbar direkt in dem JAR befinden (...), schon. Schade.

[thmarx]

Hallo Herr Rößler,

Da die Abhängigkeit im fs-client.jar enthalten sind, müssen diese ja nicht in das Repository.

Oder wollten sie ein fs-client.jar ohne die Abhängigkeiten?

Viele Grüße

Thorsten Marx

[novomind]

Ich will eigentlich vermeiden, dass Abhängigkeiten doppelt in den Classpath geladen werden oder schlimmer: in einer anderen Version in den Classpath geladen werden, denn das kann zu Seiteneffekten führen, die nur schwer reproduzierbar sind. Daher auch die Idee mit Maven, hier kann man die Dependencies besser verwalten.

Meine Idealvorstellung wäre ein fs-client.jar, dass den FS Code enthält und selbst Abhängigkeiten wie slf4j, google gdata, jgraph, apache commons etc. zieht, die ich bei Bedarf auch durch neuere Versionen ersetzen kann.

[Hendrik]

Hallo Herr Rößler,

da beim Classloading im FirstSpirit Server meines Wissens benötigte Klassen ersteinmal in den Bibliotheken des  FirstSpirit Servers gesucht werden (m.E. ein Bug) und erst anschließend auf die durch Module bereitsgestellten globalen oder moduleigenen Bibliotheken zurückgegriffen wird, lassen sich Redundanzem im Classpath genaugenommen nur dann vermeiden wenn sie auf Bibliotheken aufsetzen der Server bereits mitbringt sofern sie Bibliotheken verwenden die auch der Server verwendet. Bspw. bringt der Server ein commons-io mit, wenn Ihr Modul ein eigenes commons-io mitbringt in einer anderen Version so wird serverseitig bei der Ausführung Ihres Code die commins-io Bibliothek des Servers verwendet!

Wir verwenden in unseren Projekten ebenfalls Maven und haben ein eigenes Repository aufgesetzt in welches wir regelmäßig die fs-access.jar, fs-webrt.jar etc. deployen. Da die FirstSpirit Bibliotheken m.W. nicht mit Maven gebaut werden bringen diese auch keine Transienten Bibliotheken mit, auf diese Weise werden Sie keine redundanten Bibliotheken bspw. in der Eclipse IDE bekommen.

Die Idee das z.B. die Abhängigkeiten des fs-client.jar abänderbar sind halte ich für Riskant, wie soll der Hersteller auf diesem Wege für die Funktion der Bibliothek garantieren?

[novomind]

Hallo, Herr Holst.

Schaut man mal in die fs-client.jar, stellt man fest, dass nicht nur espirit libraries dort enthalten sind, sondern alle transitiven Abhängigkeiten auch, z.B. Google Gdata, Jgraph, Javax Mail, Activation, javax Annotation, apache commons logging/lang, httpclient uvm.

Mal davon abgesehen, dass ich nicht weiß, in welchen Versionen diese vorhanden sind: Bringe ich nun bspw. eine eigene Abhängigkeit z.B. apache httpclient mit, wer garantiert mir, dass immer die gleiche Version geladen wird, ob die von mir mitgebrachte oder die aus der fs-client.jar....IMHO kann mir das keiner garantieren, dementsprehend kann dies dazu führen, dass bei einem Start die Lib aus der JAR geladen wird, das andere mal die Lib, die ich mitbringe. Gibt es in diesen Libs nun Unterschiede in Implementierungen o.ä. kann das beim ersten Mal zu unerwünschten Verhalten führen, beim zweiten Mal nicht...also ein schwer reproduzierbares Problem.

Streng genommen dürfte ich also KEINE der Libs mitbringen, die die fs-client.jar enthält, angefangen beim log4j bis hin zu javax mail.

Es klingt alles ein bißchen konstruiert, nur möchte ich dieses Problem nicht wegignorieren, da es durchaus real ist....

[Hendrik]

Hallo Herr Rößler,

die fs-client.jar bringt eine Menge transitiver Abhängigkeiten mit, das ist korrekt. Ich bin jedoch der Auffassung dass die Implementierung eigener Module unabhängig von diesen Bibliotheken erfolgen muss. Das Classloading Verhalten der zugrunde liegenden Plattform (Client oder Server) sollte so ausgerichtet sein, dass die Bibliotheken der Plattform bei der Ausführung von Code aus Modulen, die ihre eigenen Bibliotheken mitbringen, erst dann verwendet werden wenn die Bibliotken der Module die benötigten Klassen nicht enthalten, wenn überhaupt. Denn wenn die Bibliotheken der zugrunde liegende Plattform bei der Ausführun modulspezifischen Codes verwendet werden kann dies, wie von Ihnen beschrieben, zu unerwartetem Verhalten führen was unbedingt zu vermeiden ist, da bin ich ganz bei Ihnen.

Leider funktioniert das Classloading Verhalten nicht so wie ich es erwarten würde, wie ich im vorigem Post bereits am Beispiel der commons-io beschrieben habe, wodurch wir bereits Probleme bei der Ausführung von Code eines unsere Module bekommen haben. Meiner Meinung nach ist die ein Fehlverhalten des Servers (ob es im Client ebenfalls nicht korrekt funktioniert habe ich noch nicht getestet) zu welchem ich bereits mit eSpirit über das Helpdesk Kontakt aufgenommen habe.

Welches Verhalten seitens eSpirit als "korrekt" hinsichtlich des Classloadings angesehen wird ist mir dabei nicht ganz klar. Da jedoch für die Entwicklugn von Modulen keinerlei Informationen über die im Server oder Client laufenden Bibliotheken verfügabr sind kann "korrekt" meiner Meinung nach eigentlich nur ein von der Plattform unabängiges Classloading mit den Bibliotheken der Module sein. Eine Vorgabe der Bibliotheken durch die ausführende Plattform halte ich ohnehin für fragwürdig, es kann ja nicht sein dass man sich bei der Entwicklung von Modulen auf Klassen beschränken muss die aus Bibliotheken der Plattform kommen. Was ist wenn man bspw. Klassen aus einer commons-io in der Version 1.4 benötigt, die Plattform jedoch nur ein commons-io in der Version 1.3 beinhaltet?

Wir halten es bei der Entwicklung eigener Module diesem Ansatz folgend ohnehin so das die die fs-client.jar nicht als Bibliothek genutzt wird, lediglich die fs-access.jar sowie die fs-webrt.jar da nur diese Bibliotheken den Stabilittätskriterien des Herstellers unterliegen zumal wir vermeiden wollen das bei der Entwicklung Klassen verwendet werden die nicht Teil der Access oder Developer API sind.

Wir hatten tatsächlich schon Probleme (ClassNotFoundException und NoSuchMethodException) die durch die angerissene Problematik entstanden sind, daher bin ich auch der Meinung das dies eine ernst zu nehmende Problematik ist und es aktuell ein wenig zum "Glücksspiel" wird auf die richtigen Bibliothken zu setzen..