JBoss: Versionskonflikte von log4j
Robert Schroeder
Unsere Firma setzt als Applikationsserver den JBoss 2.4.3 ein.
Nun möchten wir in unsere Applikation eine Fremdbibliothek benutzen, die
zum Logging log4j benutzt - in der Version 1.2.8.
Nun bringt der JBoss sein eigenens log4j mit - in der Version 1.1.2.
Wenn nun die Frembibliothek loggen möchte, tritt dieser Fehler auf:
STDERR:22.06.2004/20:09:59: java.lang.VerifyError: (class:
org/apache/log4j/LogManager, method: <clinit> signature: ()V)
Incompatible argument to function
STDERR:22.06.2004/20:10:00: at
org.apache.log4j.Logger.getLogger(Logger.java:85)
JBoss findet sein eigenes log4j im Classpath eher als das aktuelle log4j.
Bei google findet man einige Beiträge zu dem Thema, aber es beschränkt
sich meistens nur auf die Beschreibung des Problems.
Habt ihr Ideen, wie man das Problem lösen kann?
Ich hatte ursprünglich gedacht, JBoss würde den Classpath der
gestarteten Anwendungen von seinem getrennt halten, so daß JBoss für
sich sein altes log4j weiterhin benutzen kann und unsere Anwendung auf
die aktuelle Version zugreifen kann.
In der JBoss-Doku hab ich nichts entsprechendes gefunden und auf
jboss.org stand auch nchts, was mir geholfen hat. (Vielleicht sehe ich
aber auch nur den Wald vor lauter Bäumen nicht mehr.)
JBoss 2.4.3 ist bei uns Produktivumgebung, ein Umstieg auf eine aktuelle
JBoss-Version wäre also keine Alternative. Und der Verzicht auf die
Fremdbibliothek (für die wir nicht die Sourcen haben) steht auch nicht
zur Debatte.
Robert
PS: Stand nicht irgendwann mal ein Artikel zu Versionskonflikten in der
ix? Ich will aber nicht (wirklich) einen eigenen Classloader schreiben,
um die aktuelle log4j-Version nutzen zu können.
Tim Perkuhn
auf der Mailingliste von jakarta commons hatte jemand mit WebSphere 5.1
ein Problem das sich ähnlich anhört.
Ich poste den Thread hier damit du dir dein eigenes Bild machen kannst:
Hello All,
Thanks to all who have responded to this post.
Here are the settings that solved the problem:
After deploying J2EE app (.ear) on WAS 5.1, make sure you have
Classloader mode as PARENT_LAST and WAR Classloader Policy as
Application.
Now it's logging all messages it is supposed to log, just like the app
on WAS 4.0.4.
Reddy Pingili
>> -----Original Message-----
>> From: David J. M. Karlsen [SMTP:da...@davidkarlsen.com]
>> Sent: Tuesday, June 22, 2004 6:30 AM
>> To: robertbur...@blueyonder.co.uk
>> Cc: Jakarta Commons Users List
>> Subject: Re: [logging] Logging problems with log4j
>>
>> robert burrell donkin wrote:
>>
>> That's because websphere5.1 uses commons-logging itself - try setting
>> your EAR to use PARENT_LAST classloading - so that the classes you
>> provide (and commons-logging.properties) are found first.
>>
>> Kind regards,
>>
>> David Karlsen
>>
>
>>> > hi
>>> >
>>> > i don't know of any particular problems with websphere 5.1 (does
anyone
>>> > else?) but classpath issues are common in containers. you might
have
>>> > more luck using an alternative configuration mechanism such as
the jdk
>>> > 1.3 jar service discovery mechanism.
>>> >
>>> > if you really want to use this commons-logging.properties file
>>> > mechanism then it's possible that if websphere has a version of
>>> > commons-logging in it's root classloader then you'll need to put
it in
>>> > the root. of course, if this is the case, you'll also need to
drop in
>>> > the newer jar over the older.
>>> >
>>> > - robert
>>> >
>>> > On 21 Jun 2004, at 21:17, Pingili, Madhupal wrote:
>>> >
>>
>>>> >> Hello All,
>>>> >> I am new to this user list. I am using commons logging latest
>>>> >> version which uses log4j in a web application:
>>>> >>
>>>> >> commons-logging.properties:
>>>> >>
>>>> >>
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLog
>>>> >>
>>>> >> I have log4j.properties in the web app classpath i.e.
>>>> >> /WEB-INF/classes/log4j.properties.
>>>> >>
>>>> >> When I deploy this web app on WebSphere 5.1, it looks like
log4j is not
>>>> >> initializing at all.
>>>> >> It is not creating any log files for any log messages to be
written.
>>>> >>
>>>> >> Are there any known problems with commons-logging on WebSphere 5.1?
>>>> >>
>>>> >> Any help is appreciated.
>>>> >>
>>>> >>
>>>> >> Reddy Pingili
Carsten Birkelbach
> Unsere Firma setzt als Applikationsserver den JBoss 2.4.3 ein.
2.4.3 Uiiii.
> JBoss findet sein eigenes log4j im Classpath eher als das aktuelle log4j.
> Bei google findet man einige Beiträge zu dem Thema, aber es beschränkt
> sich meistens nur auf die Beschreibung des Problems.
> Habt ihr Ideen, wie man das Problem lösen kann?
Die einzige Lösung, die mir spontan einfällt, wäre es, die Bibliothek
zentral auszutauschen. Kann aber im Moment nicht überblicken, was das
für Änderungen für die anderen Verfahren (ich gehe mal von der Existenz
aus) das mit sich bringt.
> Ich hatte ursprünglich gedacht, JBoss würde den Classpath der
> gestarteten Anwendungen von seinem getrennt halten, so daß JBoss für
> sich sein altes log4j weiterhin benutzen kann und unsere Anwendung auf
> die aktuelle Version zugreifen kann.
Das Problem ist IMHO, dass das Logging zentral als Dienst zur Verfügung
gestellt wird. Bei registrieren des Loggers tritt nun die Inkompatilität
auf. Der Logger versucht sich beim LogManager zu registrieren und an der
Stelle knallt es, da die Klassen nicht gleich sind.
> JBoss 2.4.3 ist bei uns Produktivumgebung, ein Umstieg auf eine aktuelle
> JBoss-Version wäre also keine Alternative.
Hätte nicht gedacht, dass eine solch alte Version noch produktiv
eingesetzt wird.
Und der Verzicht auf die
> Fremdbibliothek (für die wir nicht die Sourcen haben) steht auch nicht
> zur Debatte.
Habt ihr schon mal mit dem Hersteller der Bib über dieses Problem
gesprochen?
Ansonsten würde ich das ganze als log4j und nicht als ein jboss-Problem
einordnen.
/carsten
Robert Schroeder
Nachdem ich verschiedene Sachen probierte, habe ich mich letztendlich an
das gewagt, was ich wohl als erstes hätte tun sollen: Ich hab JBoss
gepatcht!
JBoss hat mit org.jboss.logging den Zugriff auf log4j gekapselt. Es
mußten nur die beiden Klassen JBossCategory und ConsoleAppender aus dem
Unterpackage spi angepaßt werden. Der geänderter Quellcode findet sich
bei Interesse hier: http://www.suyu.de/jboss/jboss_log4j1.2.8_patch.zip
Damit loggt JBoss 2.4.3 unter Benutzung von log4j 1.2.8 und wir können
unsere Fremdbibliothek benutzen.
Robert