log4j, commons logging, log4j.properties and co

[DEvent]

Hallo
irgendwie komme ich hier nicht weiter. Ich benutze Apache Commons Logging fuer Log-Ausgaben. Wenn ich es richtig verstanden habe, dann benutzt das Log4J, wenn es den installiert ist. Das ist es auch und ich bekomme auf die Konsole Log-Ausgabe.

Aber wohin kommt die log4j.properties? Ich hab gesucht und es steht es gehoert ins Classpath. Aber egal wohin ich das log4j.properties reintue, es wird ignoriert.

Also wenn man a) Commons-Logging benutzt, b) es Log4J benutzt und c) man eine log4j.properties im Classpath hat, dann wird log4j mit der log4j.properties automatisch konfiguriert? Oder habe ich da was total falsch verstenden und es funktioniert anders?

 

[maki]

Wozu commons-logging wenn du log4j nutzt?

 

[DEvent]

Was ist eigentlich javax.jms:jms:jar:1.1 und wieso ist es nicht mehr in den Maven Repositories?

Missing:
----------
1) javax.jms:jms:jar:1.1

 

[ps]

JMS = Java Messaging Service
das ist ein Bestandteil von JavaEE und dient der asynchronen Kommunikation... wenn du nicht weißt was es ist, stehen die Chancen gut das du es nicht brauchst.

Zu deinem Logproblem:
Wieso nicht einfach das Logging API aus dem JDK benutzen? Seit java 5 bietet log4j eigentlich keine vorteile mehr. Eine abstraktionsschicht wie commons-logging erst recht nicht. Aber gut, das ist wahrscheinlich Geschmackssache 🙂
Um deine Frage zu beantworten: Ja, wenn log4j von commons-logging benutzt wird dann wird die log4j.properties im / classpath benutzt (also auf der untersten ebene, kein package).

 

[maki]

Wieso nicht einfach das Logging API aus dem JDK benutzen? Seit java 5 bietet log4j eigentlich keine vorteile mehr.

log4j kann mehr, gibt es viel länger und ist auch angenehmer zu benutzen.
imho war die Java Logging API ein Fehler.

 

[Oni]

für die meisten zwecke ist die java logging api doch völlig ausrreichend und man hat den vorteil, dass man nicht immer eine zusatz-librarie im classpath haben muss.
sobald java installiert ist, läuft der logger, ich sehe das als klaren vorteil.

 

[maki]

für die meisten zwecke ist die java logging api doch völlig ausrreichend und man hat den vorteil, dass man nicht immer eine zusatz-librarie im classpath haben muss.
sobald java installiert ist, läuft der logger, ich sehe das als klaren vorteil.

Ich weiss nicht in was für Projekten du arbeitest, in meinen sind dutzende bis hunderte jars drinnen, da ist log4j immer dabei, dadurch ist es für mich kein Nachteil.

 

[Oni]

jo, schon klar das es in "großen" projekten nicht wirklich darauf ankommt.

aber wir haben hier zum beispiel ein paar applet's die zum teil über isdn verbindungen aufgerufen werden. da ist der client garantiert nicht glücklich wenn er erstmal einen jar-file herunterladen muss der nur für das loggen gut ist.

bin halt der meinung das die java logging api aufjedenfall seine daseinsberechtigung hat.

 

[maki]

Klar kann man in kleineren Projekten die Java Logging API verwenden, eine "daseinberechtigung" allerdings spreche ich der API ab.

Wozu denn?
log4j war viel früher da, getestet, ausgereift, viele Funktionen etc.

Wozu etwas schlechter nachbauen?
War wohl eher eine politische Entscheidung.

 

[DEvent]

Aber wieso ist log4j so gross? ueber 450 Kilobyte und dabei sind noch die Abhaenigkeiten gar nicht dabei?

Ist eigentlich log4j nicht in der JRE mit dabei? Ich hab mein Projekt auf einem anderen PC mit nur einer JRE installiert und dabei wurde log4j benutzt.

Wieso wird dann meine log4j.properties ignoriert?

Naja ich hab jetzt einfach das Java Logging genommen, fuer meine Zwecke reicht es.

 

[musiKk]

Also zu sagen, dass etwas "schlechter" nachgebaut ein Fehler ist, halte ich fuer falsch. Im Gegenteil... wenn man wirklich ein Projekt hat, welchem die einfacheren (ich weiss nicht, ob die Funktionen wirklich einfacher sind, ich habs noch nicht verwendet) Funktionen des JRE reichen, hat man wieder eine Lib gespart.

Ich finde es auch ausgezeichnet, dass es mit Derby eine eingebaute Datenbank gibt, obwohl man ja MySQL oder sonstwelche nehmen koennte. Aber da muss man sich wieder drum kuemmern, dass es auch installiert ist. Zu sagen "Version xy des JRE ist benoetigt" ist imho einfacher.

 

[maki]

Ich finde es auch ausgezeichnet, dass es mit Derby eine eingebaute Datenbank gibt, obwohl man ja MySQL oder sonstwelche nehmen koennte. Aber da muss man sich wieder drum kuemmern, dass es auch installiert ist. Zu sagen "Version xy des JRE ist benoetigt" ist imho einfacher.

JavaDB == Derby

😉

Hätte man imho mit log4j auch machen sollen, zum Standard erheben, ähnlich wie beim Tomcat, anstatt es selber schlechter nachzubauen, wie gesagt, war wohl etwas "politisches".

 

[musiKk]

dass es mit Derby eine eingebaute Datenbank gibt

JavaDB == Derby

Sag ich doch... und wenn nicht, dann meinte ich es zumindest.