2012-07-20 9 views
5

Ich habe ein sehr kleines Java-Programm, das FTP über SSL (nicht SFTP) oder FTPS mit Apache-Commons-Net-Bibliothek durchführen kann. Der Grund, warum ich dieses Programm geschrieben habe, ist der Client-Rechner AIX 5.3, der FTP über SSL nicht unterstützt (OOTB), und der FTP-Host-Rechner läuft FileZilla Server mit nur FTP über SSL aktiviert. Das Programm läuft problemlos ohne Probleme, aber die Menge an Protokollierung ist riesig. Meine Frage ist - Gibt es eine Möglichkeit, die Menge der Protokollierung zu steuern?Controlled Logging für Apache-commons-net lib (Java)

(Hinweis Wieder - Das Programm arbeitet absolut in Ordnung für meine minimalistische Forderung)

Im Folgenden ein Ausschnitt aus meinem Code ist

import java.io.*; 
import java.text.MessageFormat; 
import java.util.logging.Logger; 
import org.apache.commons. 
..... 
.... 
.... 
try { 
      int reply; 
      logger.info("# Invoking Trust Manager"); 
      client.setTrustManager(TrustManagerUtils.getAcceptAllTrustManager()); 
      //client.setTrustManager(TrustManagerUtils.getValidateServerCertificateTrustManager()); 
      logger.info("# Connect Call"); 
      client.connect(server, port); 
      client.login(username, password); 
      logger.info("# Login Success"); 

      client.setFileType(FTP.ASCII_FILE_TYPE); 
      client.execPBSZ(0); // Set protection buffer size 
      client.execPROT("P"); // Set data channel protection to private 
      client.enterLocalPassiveMode(); 

      logger.info(MessageFormat.format("Connected to {0} .", server)); 
      reply = client.getReplyCode(); 
      if (!FTPReply.isPositiveCompletion(reply)) { 
       client.disconnect(); 
       logger.severe("FTP server refused connection."); 
       System.exit(1); 
      } 

      if (flag.equals("-d")) { //Dir mode 
       if (args.length == 7){ 
        renameFile = args[6]; //copy rename token 
       } 
       //We will get the file listing and stream the output to create files 
       logger.info("# Invoked Directory mode"); 
       client.changeWorkingDirectory(remoteFile); 
       FTPFile[] ftpFiles; 
       ftpFiles = client.listFiles(remoteFile); 
       if (ftpFiles != null && ftpFiles.length > 0) {      
        for (FTPFile file : ftpFiles) { 
         if (!file.isFile()) { 
          continue; 
         }       
         InputStream fin = client.retrieveFileStream(remoteFile + "/" + file.getName()); 
         if (fin == null) { 
          logger.severe(MessageFormat.format("could not retrieve file: {0}", file.getName())); 
          continue; 
         } 
         // write the inputStream to a FileOutputStream 
         OutputStream out = new FileOutputStream(new File(localFile + "/"+ renameFile + file.getName())); 
         int read = 0; 
         byte[] bytes = new byte[1024]; 

         while ((read = fin.read(bytes)) != -1) { 
          out.write(bytes, 0, read); 
         } 
         fin.close(); 
         out.flush(); 
         out.close(); 
         fin = null; 
         client.completePendingCommand(); 
        } 
       } 
      } 

      if (flag.equals("-f")) { //File mode 
       //Transfer a single file 
       logger.info("# Invoked File mode"); 
       client.listFiles(); 
       boolean retrieved = client.retrieveFile(remoteFile, new FileOutputStream(localFile)); 

       if (retrieved) { 
        logger.info("# File copied."); 
       } 
      } 
     } catch (Exception e) { 
      if (client.isConnected()) { 
       try { 
        client.disconnect(); 
       } catch (IOException ex) { 
        ex.printStackTrace(); 
       } 
      } 
      logger.severe("!! Could not connect to server.!! Please retry!"); 
      e.printStackTrace();    
     } finally { 
      client.disconnect();    
      logger.info("# FTP Client disconnected"); 
      System.exit(0); 
     } 

Die log es eine Datei zu übertragen erzeugt wie unten-

Jul 20, 2012 5:00:08 AM com.mff.ftps.FTPSSLTool main 
INFO: Connecting to IP: 216.153.173.246 on Port: 00890 
Jul 20, 2012 5:00:09 AM com.mff.ftps.FTPSSLTool main 
INFO: # Initiating SSL connection 
Jul 20, 2012 5:00:09 AM com.mff.ftps.FTPSSLTool main 
INFO: # Invoking Trust Manager 
Jul 20, 2012 5:00:09 AM com.mff.ftps.FTPSSLTool main 
INFO: # Connect Call 
IBMJSSEProvider2 Build-Level: -20110513 
keyStore is: /usr/java6_64/jre/lib/security/cacerts 
keyStore type is: jks 
keyStore provider is: 
init keystore 
SSLContextImpl: Using X509ExtendedKeyManager com.ibm.jsse2.xc 
SSLContextImpl: Using X509TrustManager org.apache.commons.net.util.TrustManagerUtils$TrustManager 
Installed Providers = 
    IBMJSSE2 
    IBMJCE 
    IBMJGSSProvider 
    IBMCertPath 
    IBMSASL 
    IBMXMLCRYPTO 
    IBMXMLEnc 
    Policy 
    IBMSPNEGO 
JsseJCE: Using SecureRandom from provider IBMJCE version 1.2 
trigger seeding of SecureRandom 
done seeding SecureRandom 
IBMJSSE2 to send SCSV Cipher Suite on initial ClientHello 
JsseJCE: Using cipher AES/CBC/NoPadding from provider TBD via init 
IBMJSSE2 will allow RFC 5746 renegotiation per com.ibm.jsse2.renegotiate set to none or default 
IBMJSSE2 will not require renegotiation indicator during initial handshake per com.ibm.jsse2.renegotiation.indicator set to OPTIONAL or default taken 
IBMJSSE2 will not perform identity checking against the peer cert check during renegotiation per com.ibm.jsse2.renegotiation.peer.cert.check set to OFF or default 
JsseJCE: Using MessageDigest MD5 from provider IBMJCE version 1.2 
JsseJCE: Using MessageDigest SHA from provider IBMJCE version 1.2 
JsseJCE: Using MessageDigest MD5 from provider IBMJCE version 1.2 
JsseJCE: Using MessageDigest SHA from provider IBMJCE version 1.2 
%% No cached client session 
*** ClientHello, SSLv3 
RandomCookie: GMT: 1342778411 bytes = { 246, 135, 47, 123, 204, 170, 94, 224, 76, 244, 28, 242, 63, 243, 124, 13, 93, 156, 170, 88, 91, 79, 89, 55, 157, 135, 214, 250 } 
Session ID: {} 
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RENEGO_PROTECTION_REQUEST] 
Compression Methods: { 0 } 
*** 
main, WRITE: SSLv3 Handshake, length = 81 
main, READ: SSLv3 Handshake, length = 74 
*** ServerHello, SSLv3 
RandomCookie: GMT: 1342778410 bytes = { 142, 39, 57, 18, 38, 123, 184, 245, 24, 29, 238, 158, 68, 17, 226, 210, 53, 31, 36, 225, 52, 166, 78, 116, 251, 98, 122, 4 } 
Session ID: {143, 221, 201, 170, 184, 190, 241, 94, 223, 253, 199, 199, 50, 161, 233, 224, 88, 78, 82, 162, 13, 222, 236, 56, 215, 253, 101, 12, 39, 45, 126, 203} 
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5 
Compression Method: 0 
*** 
Server did not supply RI Extension - com.ibm.jsse2.extended.renegotiation.indicator=optional or default - processing will continue 
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5] 
** SSL_RSA_WITH_RC4_128_MD5 
main, READ: SSLv3 Handshake, length = 1361 
*** Certificate chain 
chain [0] = [ 
[ 
    Version: V3 
    Subject: CN=ftps.thillsecure.com, OU=Terms of use at www.verisign.com/rpa (c)05, OU=Thill Logistics, O=TCFC LLC, L=Neenah, ST=Wisconsin, C=US 
    Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 

    Key: IBMJCE RSA Public Key: 
modulus:134055911103149706293270567805752446004906288958857850 
public exponent: 
65537 

    Validity: [From: Sun Dec 04 18:00:00 CST 2011, 
       To: Wed Dec 12 17:59:59 CST 2012] 
    Issuer: CN=VeriSign Class 3 Secure Server CA - G3, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US 
    SerialNumber: [168622087069244624687861365106323602194] 
.... 
.... 
.... 
Hundreds and hundreds of more lines 

ich verwende java.utils.logging.Logger für meine eigene Protokollierung Zweck, aber die Linien der Protokolle sind getti ng verschleiert durch die zahlreichen Protokollzeilen, die von den apache-commons-net Bibliotheksmethoden selbst erzeugt werden.

Also nochmal - Die Frage ist - "Gibt es eine Möglichkeit, dieses Protokollierungsverhalten der apache-commons-net Bibliothek selbst zu steuern? Irgendwelche Methode, die ich verwenden kann oder irgendeine Markierung, die gesetzt werden muss?"

UPDATE:

Ich habe endlich die Protokollierung zu steuern (Besonderer Dank geht an Flavio). Alles, was ich tun musste, war System.setProperty("javax.net.debug", "false"); in meinem Code. Ich hatte es zunächst als System.setProperty("javax.net.debug", "ssl"); eingerichtet, die Debug-Level-Protokollierung aktiviert. Jetzt sind die Protokolle viel kürzer und präziser. Es war auch offensichtlich, dass die Logbücher nicht aus der Commons-Net-Bibliothek stammten, sondern aus der javax.net. Das Protokoll ist viel kürzer und sieht etwas wie unten-

Jul 30, 2012 9:03:16 AM com.mff.ftps.FTPSSLTool main 
INFO: Connecting to IP: xxx.xxx.xxx.xxx on Port: 890 
Jul 30, 2012 9:03:16 AM com.mff.ftps.FTPSSLTool main 
INFO: # Initiating SSL connection 
Jul 30, 2012 9:03:16 AM com.mff.ftps.FTPSSLTool main 
INFO: # Invoking Trust Manager 
Jul 30, 2012 9:03:16 AM com.mff.ftps.FTPSSLTool main 
INFO: # Connect Call 
220 GlobalSCAPE Secure FTP Server 
USER XXXXXXX 
331 Password required for XXXXXXX. 
PASS XXXXXXXXX 
230 Login OK. Proceed. 
Jul 30, 2012 9:03:22 AM com.mff.ftps.FTPSSLTool main 
INFO: # Login Success 
TYPE A 
200 Type set to A. 
PBSZ 0 
200 PBSZ Command OK. Protection buffer size set to 0. 
PROT P 
200 PROT Command OK. Using Private data connection 
Jul 30, 2012 9:03:24 AM com.mff.ftps.FTPSSLTool main 
INFO: Connected to xxx.xxx.xxx.xxx . 
CWD /Data/Inv 
Jul 30, 2012 9:03:24 AM com.mff.ftps.FTPSSLTool main 
INFO: # Invoked Directory mode 
250 Folder changed to "/Data/Inv". 
SYST 
215 UNIX Type: L8 
PASV 
227 Entering Passive Mode (216,153,173,246,109,220). 
LIST /Data/Inv 
150 Opening ASCII mode data connection for file list. 
226 Transfer complete. 1430 bytes transferred. 1278 Bps. 
Jul 30, 2012 9:03:30 AM com.mff.ftps.FTPSSLTool main 
INFO: # FTP Client disconnected 

Antwort

4

Ich denke, dass Sie an der falschen Stelle suchen; Diese Nachrichten stammen nicht aus der Apache Commons-Netzbibliothek.

Ich denke, sie sind von der IBMJSSEProvider2 Sie sehen in den ersten Zeilen verwiesen. Gemäß diesen link sollten Sie in der Lage sein, sie zu deaktivieren, indem Sie nicht der System-Eigenschaft javax.net.debug, oder leiten Sie sie mit den os400.stdout und os400.stderr Eigenschaften.

+0

Super! Genau das habe ich gesucht. Ich hatte so etwas in meinem Code 'System.setProperty (" javax.net.debug "," ssl ");' und ich änderte es in 'System.setProperty (" javax.net.debug "," false ") ; '. das hat das Logging drastisch reduziert, dank einer Tonne. – Annjawn

0

Sie die Protokollebene Ihrer Anwendung einstellen können mit setLevel(). Die Klasse Level wird verwendet, um zu definieren, welche Nachrichten in das Protokoll geschrieben werden sollen. Sie können eine der folgenden Log-Stufen einstellen:

  • Level.SEVERE (höchste Stufe)
  • Level.WARNING
  • Level.INFO
  • Level.CONFIG
  • Level.FINE
  • Level.FINER
  • Level.FINEST

Wenn Sie LOGGER.setLevel(Level.INFO) verwenden, wird jeder Protokollebene höher oder gleich INFO in das Protokoll geschrieben werden, d.h, SEVERE, WARNING and INFO. Außerdem haben Sie die Ebenen Level.OFF und Level.ALL, um die Abmeldung auszuschalten oder alles zu protokollieren.

Fügen Sie Ihrer Anwendung einen höheren Protokollierungsgrad hinzu, z. B. logger.setLevel(Level.SEVERE).

Beispiel

public void writeLog() { 
    // Set the LogLevel to Severe, only severe Messages will be written 
    LOGGER.setLevel(Level.SEVERE); 
    LOGGER.severe("Severe Log"); 
    LOGGER.warning("Warning Log"); 
    LOGGER.info("Info Log"); 
    LOGGER.finest("Really not important"); 

    // Set the LogLevel to Info, severe, warning and info will be written 
    // Finest is still not written 
    LOGGER.setLevel(Level.INFO); 
    LOGGER.severe("Severe Log"); 
    LOGGER.warning("Warning Log"); 
    LOGGER.info("Info Log"); 
    LOGGER.finest("Really not important"); 
} 

Weitere Informationen: http://www.vogella.com/articles/Logging/article.html

P. S. seien Sie vorsichtig mit Ihrer logging.properties Datei, die Ihre global log level setzt.

+0

Danke für die Antwort. Aber kontrolliert das das Apache-Commons-Net Logging? Die meisten Zeilen des Protokolls, die Sie in der obigen Frage sehen, stammen aus der Bibliothek 'apache-commons-net' und nicht aus meiner Klassendatei. Wie Sie sehen können, wird jeder Schritt von Keystore über Cokkies bis zur Zertifikatskette gedruckt. An dieser Stelle möchte ich die Protokollierung der Bibliothek selbst steuern (nicht meine Protokollierung auf Programmebene), da ich nicht viele Details sehen möchte. Diese Details sind normalerweise hilfreich beim Debuggen/Entwickeln. – Annjawn

+0

Basierend auf dieser [Frage] (http://stackoverflow.com/questions/5009658/adjust-logging-level-for-apache-commons-logging?answertab=active#tab-top), denke ich, es wird nicht funktionieren. Versuchen Sie, Ihre Eigenschaftendatei mit der gewünschten Stufe zu ändern, wie in dieser Datei beschrieben: (logging.properties) to-configure-a-logger-default-values-with-a-properties.html). Es überschreibt die globalen Eigenschaften. – Yamaneko

0

Nun, ich hatte das gleiche Problem mit Spring, Quartz, Hibernate usw. APIs und Frameworks, die riesige Blöcke von Logs erstellen.

Ich legte benutzerdefinierte Ebenen für jede der APIs pro Paketbasis.

  • logger.org.spring WARN =
  • logger.org.hibernate = DEBUG
  • logger.org.quartz =
  • INFO
  • logger.com.myApp = DEBUG

Of Natürlich ist das nicht das komplette Anwesen, aber Sie bekommen die Idee. Sie könnten den Paketnamen - org.apache.commons verwenden und diesem Paket eine Protokollstufe zuweisen. Bitte beachten Sie: Jedes Protokoll von jeder Klasse unter dieser Paket-Ebene würde mit der gleichen Stufe konfiguriert werden.

Ich verwendete Slf4j über Log4j (http://www.slf4j.org/), anstelle von Util-Logger. Aber ich bin mir sicher, dass der Fehler in Ihrer Situation ein wenig verdreht sein könnte. Wenn ich ein wenig fett bin, würde ich empfehlen, SLF4J zu verwenden. HTH.

0

erwartet die apache-commons-net Protokollierung entweder commons-logging oder SLF4J zu verwenden - in Abwesenheit von anderen steuernden Faktoren sollten diese Protokollierung auf java.util.logging routen.

Die ultimative Antwort hier ist, dass, wenn Sie die Protokolle in einer Ausgabedatei (nicht Konsole) vermischt sehen, dann ist es sehr wahrscheinlich, dass sie durch einen gemeinsamen Logger weitergeleitet werden. Und java.lang.logging ist hier am Werk, also lasst uns die Konfiguration versuchen.

java.util.logging konfigurieren:

Ihre Logging Eigenschaften erstellen Datei, sagen myLog.properties und Ebenen für die verschiedenen Pakete anpassen.Sie können beispielsweise eine Ebene höher als INFO - wie SCHWERE - für das widerwärtige Paket com.mff.ftps:

# handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler 
handlers=java.util.logging.FileHandler 

# Set ROOT logger level 
.level=INFO 
com.mff.ftps.level=SEVERE 
# Set any number specifications: <package.path>.level=<LOGLEVEL> 

java.util.logging.ConsoleHandler.level=WARNING 
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter 

java.util.logging.FileHandler.level=FINEST 
java.util.logging.FileHandler.pattern=myLogFile.log 
java.util.logging.FileHandler.limit=1073741824 # 1MB 
java.util.logging.FileHandler.count=2 
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter 

Wenn Sie Java starten, gibt die Protokolleigenschaftsdatei:

java -Djava.util.logging.config.file=<pathTo>/myLog.properties -cp .. .

oder Code schreiben:

File logPropFile = new File("<pathTo>/myLog.properties"); 
InputStream logPropStream = new FileInputStream(logPropFile); 
try { 
    LogManager.getLogManager().readConfiguration(logPropStream); 
} 
finally { 
    logPropStream.close(); 
} 
+0

Danke, aber die Lösung war 'javax.net.debug' einzustellen. – Annjawn