%p 输出优先级，即DEBUG，INFO，WARN，ERROR，FATAL
%r 输出自应用启动到输出该log信息耗费的毫秒数
%c 输出所属的类目，通常就是所在类的全名
%t 输出产生该日志事件的线程名
%n 输出一个回车换行符，Windows平台为“\r\n”，Unix平台为“\n”
%d 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，比如：%d{yyy MMM dd HH:mm:ss,SSS}，输出类似： 2002年10月18日 22：10：28，921
%l 输出日志事件的发生位置，包括类目名、发生的线程，以及在代码中的行数。举例：Testlog4.main(TestLog4.java:10)

一、常用输出格式

%c   列出logger名字空间的全称，如加上{<层数>}表示出从最内层算起的指定层数的名字空间
%X  按MDC（Mapped Diagnostic Context,线程映射表）输出日志。通常用于多个客户端连接同一台服务器，方便服务器区分是那个客户端访问留下来的日志。
%p  日志信息级别
%d   %d{<日期格式>}:日志信息产生时间,使用ISO8601定义的日期格式
%C   日志信息所在地（全限类名）
%m   产生的日志具体信息
%n    输出日志信息换行
%F　显示调用logger的源文件名
%l     输出日志事件的发生位置，包括类目名、发生的线程，以及在代码中的行数
%L    显示调用logger的代码行
%M   显示调用logger的方法名
%r     显示从程序启动时到记录该条日志时已经经过的毫秒数
%t     输出产生该日志事件的线程名
%%　显示一个
二、log4j.properties

#控制包中日志输出级别
log4j.logger.org.apache.struts = debug

# 应用于控制台
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.Threshold=DEBUG
log4j.appender.CONSOLE.Target=System.out
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[framework] %d - %-4r [%t] %-5p %c %x - %m%n
#log4j.appender.CONSOLE.layout.ConversionPattern=[start]%d{DATE}[DATE]%n%p[PRIORITY]%n%x[NDC]%n%t[THREAD] n%c[CATEGORY]%n%m[MESSAGE]%n%n

#应用于文件
log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=file.log
log4j.appender.FILE.Append=false
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[framework] %d - %-4r [%t] %-5p %c %x - %m%n
# Use this layout for LogFactor 5 analysis

# 应用于文件回滚
log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLING_FILE.Threshold=ERROR
log4j.appender.ROLLING_FILE.File=rolling.log
log4j.appender.ROLLING_FILE.Append=true
log4j.appender.ROLLING_FILE.MaxFileSize=100KB
log4j.appender.ROLLING_FILE.MaxBackupIndex=10
log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLING_FILE.layout.ConversionPattern=[framework] %d - %-4r [%t] %-5p %c %x - %m%n

#应用于socket
log4j.appender.SOCKET=org.apache.log4j.net.SocketAppender
log4j.appender.SOCKET.RemoteHost=localhost
log4j.appender.SOCKET.Port=5001
log4j.appender.SOCKET.LocationInfo=true
# Set up for Log Facter 5
log4j.appender.SOCKET.layout=org.apache.log4j.PatternLayout
log4j.appender.SOCET.layout.ConversionPattern=[start]%d{DATE}[DATE]%n%p[PRIORITY]%n%x[NDC]%n%t[THREAD]%n%c[CATEGORY]%n%m[MESSAGE]%n%n

# Log Factor 5 Appender
log4j.appender.LF5_APPENDER=org.apache.log4j.lf5.LF5Appender
log4j.appender.LF5_APPENDER.MaxNumberOfRecords=2000

# 发送日志给邮件
log4j.appender.MAIL=org.apache.log4j.net.SMTPAppender
log4j.appender.MAIL.Threshold=FATAL
log4j.appender.MAIL.BufferSize=10
log4j.appender.MAIL.From=web@www.wuset.com
log4j.appender.MAIL.SMTPHost=www.wusetu.com
log4j.appender.MAIL.Subject=Log4J Message
log4j.appender.MAIL.To=web@www.wusetu.com
log4j.appender.MAIL.layout=org.apache.log4j.PatternLayout
log4j.appender.MAIL.layout.ConversionPattern=[framework] %d - %-4r [%t] %-5p %c %x - %m%n

# 用于数据库
log4j.appender.DATABASE=org.apache.log4j.jdbc.JDBCAppender
log4j.appender.DATABASE.URL=jdbc:mysql://localhost:3306/test
log4j.appender.DATABASE.driver=com.mysql.jdbc.Driver
log4j.appender.DATABASE.user=root
log4j.appender.DATABASE.password=
log4j.appender.DATABASE.sql=INSERT INTO LOG4J (Message) VALUES ('[framework] %d - %-4r [%t] %-5p %c %x - %m%n')
log4j.appender.DATABASE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATABASE.layout.ConversionPattern=[framework] %d - %-4r [%t] %-5p %c %x - %m%n

#每日回滚日志文件
log4j.appender.A1=org.apache.log4j.DailyRollingFileAppender
log4j.appender.A1.File=SampleMessages.log4j
log4j.appender.A1.DatePattern=yyyyMMdd-HH'.log4j'
log4j.appender.A1.layout=org.apache.log4j.xml.XMLLayout

#自定义Appender
log4j.appender.im = net.cybercorlin.util.logger.appender.IMAppender
log4j.appender.im.host = mail.cybercorlin.net
log4j.appender.im.username = username
log4j.appender.im.password = password
log4j.appender.im.recipient = corlin@cybercorlin.net
log4j.appender.im.layout=org.apache.log4j.PatternLayout
log4j.appender.im.layout.ConversionPattern =[framework] %d - %-4r [%t] %-5p %c %x - %m%n

The significance of the class search path

This article describes in detail how the Java compiler and the JVM use the class search path to locate classes when they are referenced by other Java code. It does this with reference to a very simple example, which uses two classes in the same package. We will see how various operations to compile these two classes succeed and fail, depending on the class path setting.

To make things absolutely clear, we will use only simple command-line tools to carry out the compile operations. Interactive development tools have their own ways of manipulating the class path, which vary from product to product.

There is no fundamental difference between the way that the Java compiler searches for classes, and the way that the JVM does it at run time. However, the compiler has the ability to compile classes from source code, where the JVM does not. In the examples below we will use the compiler, but similar issues apply at run time.

The example

package com.web_tomorrow;
public class CPTest1
{
public static void main(String[] args)
  {
  System.out.println ("Run CPTest1.main()");
  }
}

package com.web_tomorrow;
public class CPTest2
{
public static void main(String[] args)
  {
  System.out.println ("Run CPTest2.main()");
  CPTest1 cpt1 = new CPTest1();
  }
}

[root]
  com
    web_tomorrow
      CPTest1.java
      CPTest2.java

Basic principles

As a first attempt, let's change directory to the location of CPTest1.java, and try to compile it by specifying its name on the javac command line.

cd [root]/com/web_tomorrow
javac -classpath "" CPTest1.java

javac -classpath "" CPTest2.java

PTest2.java:7: cannot resolve symbol
symbol  : class CPTest1  
location: class com.web_tomorrow.CPTest2
  CPTest1 cpt1 = new CPTest1();
  ^

  CPTest1 cpt1 = new CPTest1();

You might think this problem can be resolved by telling the compiler to look in the current directory. The standard symbol for `current directory' is a single period (.) in both Unix and Windows systems. So try something like this:

javac -classpath "." CPTest2.java

To make this compile operation work, we need to make the class search path reference not the directory containing CPTest1, but a directory root from which CPTest1 can be located by the compiler following the standard Java `package name = directory name' rule. This should work, although it's rather ugly:

javac -classpath "../.." CPTest2.java

javac -classpath "" CPTest1.java CPTest2.java

javac -classpath "" *.java 

A more convenient way to compile CPTest2 on its own is like this:

cd [root]
javac -classpath "." com/web_tomorrow/CPTest2.java

In fact, even though I only specified CPTest2 on the command line, this practice does in fact lead to the compilation of CPTest1 as well. The compiler finds the .java file in the right place, but it can't tell whether this Java source really implements the right class, so it has to compile it. But note that if we do this:

cd [root]
javac -classpath "." com/web_tomorrow/CPTest1.java

.class files separate from .java files

To begin we will need to delete any .class files lurking around after the previous examples. We will also contain a new directory classes to contain the generated .class files. The procedure at the command line would be something like this:

cd [root]
rm com/web_tomorrow/*.class
mkdir classes

[root]
  com
    web_tomorrow
      CPTest1.java
      CPTest2.java
  classes

cd [root]
javac -d classes -classpath "" com/web_tomorrow/CPTest1.java 

[root]
  com
    web_tomorrow
      CPTest1.java
      CPTest2.java
  classes
    com
      web_tomorrow
        CPTest1.class

cd [root]
javac -d classes -classpath classes com/web_tomorrow/CPTest2.java 

[root]
  com
    web_tomorrow
      CPTest1.java
      CPTest2.java
  classes
    com
      web_tomorrow
      CPTest1.class
      CPTest2.class

JARs on the classpath

javac -classpath /myclasses/myclasses.jar ...

Multiple class search directories

On Unix, we would do this:

javac -classpath dir1:dir2:dir3 ...

javac -classpath dir1;dir2;dir3 ...

System classpath

CLASSPATH=/myclasses/myclasses.jar;export CLASSPATH 

set CLASSPATH=c:\myclasses\myclasses.jar

Setting the system CLASSPATH is a useful procedure if you have JARs full of classes that you use all the time. For example, if I am developing Enterprise JavaBean (EJB) applications using Sun's J2EE `Reference Implementation', all the EJB-related classes are in a JAR called `j2ee.jar' that comes with the distribution. I want this JAR on the class search path all the time. In addition, most people want to ensure that the current directory is on the search path, whatever the current directory happens to be. So in my .bashrc file I have this line:

CLASSPATH=/usr/j2ee/j2ee.jar:.;export CLASSPATH 

It is easy to overlook that the -classpath option on the command line replaces the default, system class path; it does not add to it. So what should I do if I want to set the class path to include the default system classpath plus some other entries? I could simply use the -classpath option and list the default entries in addition to my extras. However, a better way is to reference the CLASSPATH environment variable. The syntax for this is different -- of course -- on Windows and Unix systems. On Unix:

javac -classpath $CLASSPATH:dir1:dir2 ...

javac -classpath %CLASSPATH%;dir1:dir2 ...

javac -classpath "%CLASSPATH%";dir1:dir2 ...


//
//the article ended! the following is got from Sun Microsystem Document.







Setting the class path
Synopsis
The class path is the path that the Java runtime environment searches for classes and other resource files. The class search path (more commonly known by the shorter name, "class path") can be set using either the -classpath option when calling a JDK tool (the preferred method) or by setting the CLASSPATH environment variable. The -classpath option is preferred because you can set it individually for each application without affecting other applications and without other applications modifying its value. 
C:>sdkTool-classpathclasspath1;classpath2...
-or-
C:> set CLASSPATH=classpath1;classpath2...
where:
sdkTool
A command-line tool, such as java, javac, javadoc, or apt. For a listing, see JDK Tools.
classpath1;classpath2
Class paths to the .jar, .zip or .class files. Each classpath should end with a filename or directory depending on what you are setting the class path to: 
For a .jar or .zip file that contains .class files, the class path ends with the name of the .zip or .jar file.
For .class files in an unnamed package, the class path ends with the directory that contains the .class files.
For .class files in a named package, the class path ends with the directory that contains the "root" package (the first package in the full package name).
Multiple path entries are separated by semi-colons. With the set command, it's important to omit spaces from around the equals sign (=).
The default class path is the current directory. Setting the CLASSPATH variable or using the -classpath command-line option overrides that default, so if you want to include the current directory in the search path, you must include "." in the new settings.
Classpath entries that are neither directories nor archives (.zip or .jar files) nor * are ignored.
Description
The class path tells JDK tools and applications where to find third-party and user-defined classes -- that is, classes that are not Java extensions or part of the Java platform. The class path needs to find any classes you've compiled with the javac compiler -- its default is the current directory to conveniently enable those classes to be found.
The JDK, the JVM and other JDK tools find classes by searching the Java platform (bootstrap) classes, any extension classes, and the class path, in that order. (For details on the search strategy, see How Classes Are Found.) Class libraries for most applications will want to take advantage of the extensions mechanism. You only need to set the class path when you want to load a class that's (a) not in the current directory or in any of its subdirectories, and (b) not in a location specified by the extensions mechanism.
If you are upgrading from an older version of the JDK, your startup settings may include CLASSPATH settings that are no longer needed. You should remove any settings that are not application-specific, such as classes.zip. Some third-party applications that use the Java Virtual Machine may modify your CLASSPATH environment variable to include the libaries they use. Such settings can remain.
You can change the class path by using the JDK tools' -classpath option when you invoke the JVM or other JDK tools or by using the CLASSPATH environment variable. Using the -classpath option is preferred over setting CLASSPATH environment variable because you can set it individually for each application without affecting other applications and without other applications modifying its value.
Classes can be stored either in directories (folders) or in archive files. The Java platform classes are stored in rt.jar. For more details on archives and information on how the class path works, see Understanding the class path and package names near the end of this document.
Important Note: Some older versions of the JDK sofware included a <jdk-dir>/classes entry in the default class path. That directory exists for use by the JDK software, and should not be used for application classes. Application classes should be placed in a directory outside of the JDK directory hierarcy. That way, installing a new JDK does not force you to reinstall application classes. For compatibility with older versions, applications that use the <jdk-dir>/classes directory as a class library will run in the current version, but there is no guarantee that they will run in future versions.
Using the JDK tools' -classpath option
The JDK tools java, jdb, javac, and javah have a -classpath option which replaces the path or paths specified by the CLASSPATH environment variable while the tool runs. This is the recommended option for changing class path settings, because each application can have the class path it needs without interfering with any other application.
The runtime tool java has a -cp option, as well. This option is an abbreviation for -classpath.
For very special cases, both java and javac have options that let you change the path they use to find their own class libraries. The vast majority of users will never to need to use those options, however.
Using the CLASSPATH environment variable
In general, you will want to use the -classpath command-line option, as explained in the previous section. This section shows you how to set the CLASSPATH environment variable if you want to do that, or clear settings left over from a previous installation.
Setting CLASSPATH
The CLASSPATH environment variable is modified with the set command. The format is:
set CLASSPATH=path1;path2 ... 
The paths should begin with the letter specifying the drive, for example, C:\. That way, the classes will still be found if you happen to switch to a different drive. (If the path entries start with backslash (\) and you are on drive D:, for example, then the classes will be expected on D:, rather thanC:.)
Clearing CLASSPATH
If your CLASSPATH environment variable has been set to a value that is not correct, or if your startup file or script is setting an incorrect path, you can unset CLASSPATH by using:
C:> set CLASSPATH=
This command unsets CLASSPATH for the current command prompt window only. You should also delete or modify your startup settings to ensure that you have the right CLASSPATH settings in future sessions.
Changing Startup Settings
If the CLASSPATH variable is set at system startup, the place to look for it depends on your operating system: 
Operating System
Method
Windows 95 and 98
Examine autoexec.bat for the set command.
Other (Windows NT, Windows 2000, ...)
The CLASSPATH environment variable can be set using the System utility in the Control Panel.
Understanding class path wildcards
Class path entries can contain the basename wildcard character *, which is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR. For example, the class path entry foo/* specifies all JAR files in the directory named foo. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory.
A class path entry that contains * will not match class files. To match both classes and JAR files in a single directory foo, use either foo;foo/* or foo/*;foo. The order chosen determines whether the classes and resources in foo are loaded before JAR files in foo, or vice versa.
Subdirectories are not searched recursively. For example, foo/* looks for JAR files only in foo, not in foo/bar, foo/baz, etc.
The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine. A well-constructed application should not depend upon any particular order. If a specific order is required then the JAR files can be enumerated explicitly in the class path.
Expansion of wildcards is done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself. Each element of the input class path containing a wildcard is replaced by the (possibly empty) sequence of elements generated by enumerating the JAR files in the named directory. For example, if the directory foo contains a.jar, b.jar, and c.jar, then the class path foo/* is expanded into foo/a.jar;foo/b.jar;foo/c.jar, and that string would be the value of the system property java.class.path.
The CLASSPATH environment variable is not treated any differently from the -classpath (or -cp) command-line option. That is, wildcards are honored in all these cases. However, class path wildcards are not honored in the Class-Path jar-manifest header.
Understanding the class path and package names
Java classes are organized into packages which are mapped to directories in the file system. But, unlike the file system, whenever you specify a package name, you specify the whole package name -- never part of it. For example, the package name for java.awt.Button is always specified as java.awt.
For example, suppose you want the Java runtime to find a class named Cool.class in the package utility.myapp. If the path to that directory is C:\java\MyClasses\utility\myapp, you would set the class path so that it contains C:\java\MyClasses.
To run that app, you could use the following JVM command:
C:> java -classpath C:\java\MyClasses utility.myapp.Cool
When the app runs, the JVM uses the class path settings to find any other classes defined in the utility.myapp package that are used by the Cool class.
Note that the entire package name is specified in the command. It is not possible, for example, to set the class path so it contains C:\java\MyClasses\utility and use the command java myapp.Cool. The class would not be found.
(You may be wondering what defines the package name for a class. The answer is that the package name is part of the class and cannot be modified, except by recompiling the class.)
Note: An interesting consequence of the package specification mechanism is that files which are part of the same package may actually exist in different directories. The package name will be the same for each class, but the path to each file may start from a different directory in the class path.
Folders and archive files
When classes are stored in a directory (folder), like c:\java\MyClasses\utility\myapp, then the class path entry points to the directory that contains the first element of the package name. (in this case, C:\java\MyClasses, since the package name is utility.myapp.)
But when classes are stored in an archive file (a .zip or .jar file) the class path entry is the path to and including the .zip or .jar file. For example, to use a class library that is in a .jar file, the command would look something like this:
C:> java -classpath C:\java\MyClasses\myclasses.jar utility.myapp.Cool
Multiple specifications
To find class files in the directory C:\java\MyClasses as well as classes in C:\java\OtherClasses, you would set the class path to:
C:> java -classpath C:\java\MyClasses;C:\java\OtherClasses ...
Note that the two paths are separated by a semicolon.
Specification order
The order in which you specify multiple class path entries is important. The Java interpreter will look for classes in the directories in the order they appear in the class path variable. In the example above, the Java interpreter will first look for a needed class in the directory C:\java\MyClasses. Only if it doesn't find a class with the proper name in that directory will the interpreter look in the C:\java\OtherClasses directory.
Copyright © 2004-2006 Sun Microsystems, Inc. All Rights Reserved.

Java Software

　　Java中文问题一直困扰着很多初学者，如果了解了Java系统的中文问题原理，我们就可以对中文问题能够采取根本的解决之道。

　　最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。

　　还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。

　　在Java内部运算中，涉及到的所有字符串都会被转化为UTF-8编码来进行运算。那么，在被Java转化之前，字符串是什么样的字符集？ Java总是根据操作系统的默认编码字符集来决定字符串的初始编码，而且Java系统的输入和输出的都是采取操作系统的默认编码。

　　因此，如果能统一Java系统的输入、输出和操作系统3者的编码字符集合，将能够使Java系统正确处理和显示汉字。这是处理Java系统汉字的一个原则，但是在实际项目中，能够正确抓住和控制住Java系统的输入和输出部分是比较难的。J2EE中，由于涉及到外部浏览器和数据库等，所以中文问题乱码显得非常突出。

　　J2EE应用程序是运行在J2EE容器中。在这个系统中，输入途径有很多种：一种是通过页面表单打包成请求（request）发往服务器的；第二种是通过数据库读入；还有第3种输入比较复杂，JSP在第一次运行时总是被编译成Servlet，JSP中常常包含中文字符，那么编译使用javac时，Java将根据默认的操作系统编码作为初始编码。除非特别指定，如在Jbuilder/eclipse中可以指定默认的字符集。

　　输出途径也有几种：第一种是JSP页面的输出。由于JSP页面已经被编译成Servlet，那么在输出时，也将根据操作系统的默认编码来选择输出编码，除非指定输出编码方式；还有输出途径是数据库，将字符串输出到数据库。

　　由此看来，一个J2EE系统的输入输出是非常复杂，而且是动态变化的，而Java是跨平台运行的，在实际编译和运行中，都可能涉及到不同的操作系统，如果任由Java自由根据操作系统来决定输入输出的编码字符集，这将不可控制地出现乱码。

　　正是由于Java的跨平台特性，使得字符集问题必须由具体系统来统一解决，所以在一个Java应用系统中，解决中文乱码的根本办法是明确指定整个应用系统统一字符集。

　　指定统一字符集时，到底是指定ISO8859_1 、GBK还是UTF-8呢？

　　（1）如统一指定为ISO8859_1，因为目前大多数软件都是西方人编制的，他们默认的字符集就是ISO8859_1，包括操作系统Linux和数据库MySQL等。这样，如果指定Jive统一编码为ISO8859_1，那么就有下面3个环节必须把握：

　　开发和编译代码时指定字符集为ISO8859_1。

　　运行操作系统的默认编码必须是ISO8859_1，如Linux。

　　在JSP头部声明：<%@ page contentType="text/html;charset=ISO8859_1" %>。

　　（2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。

　　统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。

　　那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？

　　将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。

　　一个J2EE应用系统需要做下列几步工作：

1. 开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。
2. 使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句：
   request.setCharacterEncoding("UTF-8")。
   网上有此filter的源码，Jdon框架源码中com.jdon.util.SetCharacterEncodingFilter
   需要配置web.xml 激活该Filter。
3. 在JSP头部声明：<%@ page contentType="text/html;charset= UTF-8" %>。
4. 在Jsp的html代码中，声明UTF-8:
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
5. 设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下：
   jdbc:mysql://localhost:3306/test?useUnicode=true&amp;characterEncoding=UTF-8
   注意，上述写法是JBoss的mysql-ds.xml写法，多亏网友提示，在tomcat中&amp;要写成&即可。一般其他数据库都可以通过管理设置设定UTF-8
6. 其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。