Frage/Problem bei Log4J

Eclipse und auf Eclipse basierende Toolings haben erstmal nichts mit Server Laufzeitumgebungen zu tun. D.h. die Laufzeitumgebungen wie WebSphere Application Server (kommerziell) oder Tomcat (opensource) müssen seperat verwaltet werden.

Diverse Plugins und Aufsätze auf Eclipse interagieren auch mit den Laufzeitumgebungen, z.B. deployen, Basisverwaltung dies ist dann aber in der Verantwortlichkeit des Pluginherstellers und ist generell problematisch, wegen vielen Verschiedenen Laufzeitumgebungen und sich ändernden Versionen.

Was immer geht ist ein seperater Betrieb von Entwicklungswerkzeugen und Laufzeitumgebungen, so sieht es in produktiven Umgebungen eh aus. D.h. entwickeln, dann exportieren, dann auf Server deployen.

TLDNR:
Das Verzeichniss für das log4j.ar findest du dort, wo der WebSphere Application Server installiert ist im Dateisystem.

Quick&Dirty Alternative:
Deployen aus eclipse scheint ja zu klappen. Teste doch mal den Ansatz von oben:
In deinem screenshot könntest du auch im Kartenreiter "Order und Export" das log4j.jar anhaken. Bei einem export zu war würde dann das log4j.jar mitexportiert und als Teil des wars deployed. Sowas würde man aber nicht für Bibliotheken von allgemeinem Interesse wie log4j machen, sondern eher mit anwendungsspezifischen jars.
 
Servus,

so, habe jetzt über den Server das "Administrative Script" ausgeführt. Dort wollte ich unter Classpath die Log4J.jar einbinden. Na gut, was heißt "wollte". Ich habe sie eingebunden. Wenn ich allerdings das Script wieder verlasse, dann ist die Jar-Datei nicht mehr drin. Was is das denn nu?

Habe mal den Screenshot vom Administrative Script eingefügt...
 

Anhänge

  • ServerAdministrative.JPG
    ServerAdministrative.JPG
    87,2 KB · Aufrufe: 43
Der Screenshot ist aus der scripting-Schnittstelle zum WAS. Alternativ zu der Adminconsole kann man damit über bestehende scripts (Jython, Jacl) den WAS konfigurieren. Der classpath Kartenreiter aus dem screenshot bezieht sich auf die Umgebung des verwendeten Scripts, nicht auf den Server classpath.

Wie man damit ein Jar einbindet müsste ich nachschlagen.

Ich gehe davon aus, du verwendest den Websphere Integration Developer (WID). Wesentlich leichter ist dann:
Im WID in der Server view den Server rechtsklicken, "run adminstrative console" auswählen. Die Adminconsole sollte in einem Browser aufgehen.
Dort unter "Umgebung" die Option "Gemeinsame Bibliotheken" auswählen.
Mithilfe von "Neu" die log4j lib anlegen.

Alternativen:
Die Anwendung incl. des log4j.jar als Teil des wars deployen s.o.
Das Jar per Hand in einen lib-Ordner des Servers legen z.B. WAS_ROOT/lib/ext
 
Guter Tipp :-)

Ich verwende den RSA, der dürfte ähnlich zu dem von dir beschriebenen Tool sein, denn bei mir gibts die Dinge auch, von denen du gesprochen hast.

Habe jetzt mal versucht das so anzulegen, allerdings taucht immer noch ein Fehler auf, sobald ich nur die Log4J Sachen im Code importieren will.

Deshalb vermute ich mal ,dass ich evtl. etwas falsch beim Anlegen der Jar gemacht habe? Habe davon mal einen Screenshot gemacht:
 

Anhänge

  • ServerAdminConsole.jpg
    ServerAdminConsole.jpg
    107,1 KB · Aufrufe: 45
Ja, RSA und WID haben viel gemeinsam.

Die Pfadangaben zu deinem Jar dürfen keine Backslashes enthalten, stattdessen den normalen slash "/" verwenden. Pfade dort werden optimalerweise mithilfe von bestehenden Variablen (definiert unter WebSphere-Variables) aufgebaut. z.B. ${WAS_INSTALL_ROOT}/meineLibs/log4j.jar oder
${MEINE_LIBS}/log4j.jar
Die verwendeten Variablen müssen dann noch erzeugt bzw richtig belegt werden (unter WebSphere-Variables) auch dort keine Backslashes verwenden.

Mit der Variante müssen allerdings alle Server wo die Anwendung laufen soll diese Variablen definieren, im Gegensatz zu der "deploy war incl. jar"-Variante.
 
Danke für den Tipp,

leider habe ich jetzt 2,5 Wochen keinen Zugriff auf das "Problem". Werde mich aber dann noch einmal hier melden, ob es geklappt hat.

Vielen Dank für die Hilfe.

Schöne Grüße
 
Zurück