(Java)的受控日志记录

Question

我有一个非常小的Java程序，它能够在SSL (而不是SFTP)或FTPS上执行FTP，使用库。我编写这个程序的原因是客户端机器是AIX5.3，它不支持FTP over SSL (OOTB)，而且FTP主机运行FileZilla服务器时只启用了FTP对SSL。该程序运行良好，没有任何问题，但它生成的日志量是巨大的。我的问题是-有办法控制日志记录的数量吗？

(Note再一次-该程序工作非常好，我的最低要求)

下面是我的代码片段

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);
        }

它生成的传输一个文件的日志如下所示-

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

我使用java.utils.logging.Logger作为自己的日志记录用途，但是由apache-commons-net库方法本身生成的大量日志行使日志行变得模糊不清。

所以--问题是--“有办法控制apache-commons-net库本身的日志记录行为吗?我可以使用的方法还是需要设置的标志？”

更新：

我终于控制了日志记录(特别感谢弗拉维奥)。我所要做的就是在代码中包括System.setProperty("javax.net.debug", "false");。我最初将其设置为System.setProperty("javax.net.debug", "ssl");，从而启用了调试级别日志记录。现在的日志要短得多，精确得多。同样明显的是，日志毕竟不是来自公共网络库，而是来自javax.net。原木要短得多，看上去像下面-

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

Answer 1

我认为您找错地方了；这些消息不是来自库。

我认为它们来自第一行中提到的IBMJSSEProvider2。根据这个链接，您应该能够通过不设置系统属性链接或使用os400.stdout和os400.stderr属性来禁用它们。

Answer 2

可以使用setLevel()设置应用程序的日志级别。类Level用于定义应该在日志中写入哪些消息。您可以设置以下日志级别之一：

• Level.SEVERE (最高层)
• Level.WARNING
• Level.INFO
• Level.CONFIG
• Level.FINE
• Level.FINER
• Level.FINEST

如果使用LOGGER.setLevel(Level.INFO)，则将在日志中写入每个日志级别较高或相等的INFO，即SEVERE, WARNING and INFO。此外，您还有Level.OFF和Level.ALL级别来关闭日志记录或记录所有内容。

向应用程序添加更高的日志级别，如logger.setLevel(Level.SEVERE)。

示例

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");
}

更多信息：http://www.vogella.com/articles/Logging/article.html

请注意设置logging.properties文件的全局日志级。

Answer 3

嗯，我在Spring、Quartz、Hibernate等API和框架中也遇到了同样的问题，这些API和框架产生了大量的日志。

我在每个包的基础上为每个API设置了自定义级别。

• logger.org.spring =警告
• logger.org.hibernate =调试
• logger.org.quartz = INFO
• logger.com.myApp =调试

当然，这不是完整的属性集，但是您知道了。您可以使用包名- org.apache.commons并为该包分配日志级别。请注意:该包级别下任何类的任何日志都将配置为与此相同的级别。

我使用了slf4j over log4j ( http://www.slf4j.org/)，而不是util记录器。但我相信在你的情况下这个解决办法可能会有点扭曲。如果我能大胆一点的话，我建议使用SLF4J。HTH。