warum ist ein .lck-Datei erstellt und nicht gelöscht wird von der java-Protokollierung

Ich versuche zu implementieren ist eine application-level-logger (webapps eingesetzt weblogic) - mit Hilfe von java.util.die Protokollierung .

Nahm ich die ClassLoaderLogManager von JULI apache-logging-system, da es bereits implementiert application-level-logging.

So ist dies, wie mein servlet-code (SimpleServlet.java) sieht wie folgt aus :

ClassLoaderLogManager ClassLoaderLogManager = new ClassLoaderLogManager () ;
String nameoflogger = SimpleServlet.class.getName() ;   
boolean status = ClassLoaderLogManager .addLogger(nameoflogger);   
if(status) 
{
     Logger logger = ClassLoaderLogManager .getLogger(nameoflogger);   
     logger.log(Level.FINEST, "testing SimpleServlet FINEST");
     logger.log(Level.INFO, "testing SimpleServlet INFO");
     logger.log(Level.SEVERE, "testing SimpleServlet SEVERE");   
}    
ClassLoaderLogManager .reset();

Und ich habe die Protokollierung.Eigenschaften Datei java_home/jre/lib wie folgt

handlers= java.util.logging.FileHandler

#.level= INFO

# default file output is in user's home directory.

java.util.logging.FileHandler.pattern = %h/java_%g.log
java.util.logging.FileHandler.limit = 200
java.util.logging.FileHandler.count = 10
java.util.logging.FileHandler.append  = true
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter


# Limit the message that are printed on the console to INFO and above.
#java.util.logging.ConsoleHandler.level = INFO
#java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

package8.SimpleServlet.handler = java.util.logging.FileHandler

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################

# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
package8.SimpleServlet.level = SEVERE

Also bei mir läuft die webapp - und als ich auf die webapp erwarte ich java_0.log, java_1.log ("log-Datei-rotation)- etc erstellt werden. Bin aber auch sehen, java0.log.lck, java1.log.lck .

Den log-Dateien sind nur mit STARKEN level-Protokolle wie erwartet.

Warum geschieht dies ? Wenn ich hat die Erstellung einer Prozedur, die auf der java-code der Seite , schließen Sie die Prozedur würde das Problem lösen . Kaufen y ist es nicht hier behandelt ?

Oder ist es, weil bin mit bin mit java.util.die Protokollierung.FileHandler und nicht org.apache.juli.FileHandler während der Verwendung org.apache.juli.ClassLoaderLogManager
??

  • Die sinnlose Antwort ist, dass java.util.logging ist völliger Quatsch und sollte vermieden werden, zu Gunsten von etwas besserem.
  • wenig hilfreich, eher.. ich nicht verwenden log4j. müssen, verwenden Sie diese.
InformationsquelleAutor Tom | 2011-04-20
  1. 2

    Sollten Sie erwarten, um zu sehen, lock-Dateien, wenn der FileHandler geöffnet ist. Wenn Sie sehen, wie Sie Verweilen, nachdem die VM beendet wird, dann ist es, weil die Den FileHandler nicht geschlossen wurde, wird die VM angehalten wurde oder abgestürzt ist, während der hf shutdown-hook ausgeführt wurde, oder eine I/O exception nahm Platz, während Sie versuchen, Sie zu entfernen.

    Könnten Sie ausgeführt werden, in JDK-8060132 Handler konfiguriert, der die abstrakten Knoten in der Protokollierung.Eigenschaften werden nicht immer richtig geschlossen ist. Verwandte: JDK-6274920: JDK-logger hält starken Bezug zu java.util.die Protokollierung.Logger-Instanzen.

    Blick auf die config, Sie haben ein FileHandler installiert auf dem root-logger ein FileHandler installiert auf dem SimpleServlet. Da die ClassLoaderLogManager nicht verwendet wird in einer JVM globalen Weg, den installierten Standard-LogManager ist die Schaffung der Filehandler, bevor Sie Start Ihres lokalen ClassLoaderLogManager. Entfernen Sie den FileHandler Einträge aus der java_home/jre/lib comfig Sie haben, und verwenden Sie die ClassLoaderLogManager.readConfiguration Methoden zum laden der webapp lokale Konfiguration.

    InformationsquelleAutor jmehrens
Schreibe einen Kommentar