ear包中无法通过getRealPath()获得文件的真实路径【转】
一、war包中的文件的读取
在开发J2EE Web应用时，在开发阶段通常采用目录的部署方式，而在正式运行时通常把web应用打包为单个的.war文件进行方便地部署。也就是在你的应用目录（比如WebLogic的DefaultWebApp）下，执行下面的命令：
jar cf0 mywebapp.war **
这样，要部署到正式系统时就非常方便，只需要把这个.war文件拷贝到WebLogic的applications目录或Tomcat的webapps目录下即可自动进行部署。Tomcat会对部署的.war应用包进行自动监控、解包，所以不会出现下面提到的问题。而WebLogic并不会自动解包.war，所以如果在你的应用中，需要读取原来应用中的配置文件或其它资源文件时，就会发现，在解包部署时，正常运行的程序，在WebLogic中打包部署时，运行却出错，会报告找不到该文件。例如下面的应用：
|--DefaultWebApp |--index.jsp |--.....jsp |--WEB-INF |-- web.xml |-- log4j.properties |-- classes ......
其中使用到了Log4J作为日志输出工具，Log4J的配置文件log4j.propertes放在DefaultWebApp\WEB-INF目录下。Log4J通过一个自动加载的Servlet进行初始化，初始化代码如下：
ServletContext context = getServletContext();
org.apache.log4j.PropertyConfigurator.configure(context.getRealPath("/") +
"/WEB-INF/log4j.properties");
其中，context.getRealPath("/")得到当前Web应用的真实根目录，比如，如果你的WebLogic安装在D:\bea下，在Windows下context.getRealPath("/")通常会返回：
D:\bea\wlserver6.1\config\mydomain\applications\DefaultWebApp
在UNIX下类似：
/bea/wlserver6.1/config/mydomain/applications/DefaultWebApp
这样，和"/ WEB-INF /log4j.properties"拼接后，就得到了log4j.properties文件的真实路径，Log4J通过文件IO读取这个配置文件，完成初始化。
现在一切正常！测试通过后，将DefaultWebApp下的所有文件打为一个.war包，进行部署时，发现系统报告找不到“D:\bea\wlserver6.1\null\ WEB-INF \log4j.properties”文件！如果你的应用中还需要读取其它已经被打包到war包中的文件，都会报告找不到文件。并且，系统并不会到D:\bea\wlserver6.1\config\mydomain\applications\DefaultWebApp目录下寻找，而会到D:\bea\wlserver6.1\null下寻找。这是因为context.getRealPath("/")返回了null。查看ServletContext的API文档，
public String getRealPath(String path)
……
The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).
原来，对一个打包的应用来说，是没有RealPath的概念的，调用getRealPath只会简单地返回null。其实，也很好理解，一个文件被打包入了.war文件，就不存在目录结构了（虽然包中仍然存在目录结构，但这不等同于文件系统中的目录结构）。所以，对war包中的资源是无法得到RealPath的。这样也就无从通过文件IO进行读取了。那么，如何读取war包中的资源呢？答案是使用ServletContext.getResourceAsStream(String)方法。
对于org.apache.log4j.PropertyConfigurator，有如下几种配置方法：
static void configure(Properties properties);
static void configure(String configFilename);
static void configure(URL configURL);
既然，现在不能得到war包中的Log4J的配置文件，那么可以通过读入InputStream，构造一个Properties，通过configure(Properties properties)方法同样可以完成配置。示例代码如下：
InputStream is = getServletContext().
getResourceAsStream("/WEB-INF/log4j.properties");
Properties props = new Properties();
try {
props.load(is);
} catch (IOException e) {
System.err.println("Load log4j configuration failed");
}
PropertyConfigurator.configure(props);
那么，现在对于war应用可以成功运行，但如果现在不通过war部署，直接通过目录结构部署应用会不会又出现找不到资源的错误呢？请来看看ServletContext.getResourceAsStream的API文档，
Returns a URL to the resource that is mapped to a specified path. The path must begin with a "/" and is interpreted as relative to the current context root.
This method allows the servlet container to make a resource available to servlets from any source. Resources can be located on a local or remote file system, in a database, or in a .war file.
可见，通过getResourceAsStream可以获取包括本地文件系统、远程文件系统、war包等资源。不会出现上面担心的问题。
结论：在开发J2EE Web应用时，如果需要读取本应用中的文件，尽量使用ServletContext.getResourceAsStream进行，而不要使用文件IO。
二、Ant使用中的OutOfMemoryError解决
在开发大型项目时，类文件通常有数千个之多，这时都需要采用一些make工具来辅助开发。有时需要编译的类太多，使用Ant编译时，会出现OutOfMemoryError的错误，使编译进程中断。这时，通常通过先移出部分文件，分批编译。但Java编译过程的自动依赖编译，通常很难确定究竟应该先移出哪些文件、后移出哪些文件伤透脑筋。有没有简便的方法？有！
转到你的Ant的安装目录，在bin子目录中找到ant.bat，使用文字编辑器打开，修改:runAnt处的允许命令，添加如下参数：
:runAnt
"%_JAVACMD%" -Xms128m -Xmx512m -classpath ……
如果你安装了Jike，使用Jike编译器，则需要修改:runAntWithJikes处的运行命令，同上。
结论：Java虚拟机默认分配64M内存，如果你的应用比较大，超出64M内存，Java虚拟机就会抛出OutOfMemoryError，并停止运行。不管是什么应用（Web应用、Application等），只需要修改你的机器上的运行Java命令，在java xxx命令中添加-Xms(最小使用内存)、-Xmx（最大使用内存）即可解决。当然，这儿的内存容量都是指物理内存，不能超出你的机器的物理内存的总容量。
在开发J2EE Web应用时，在开发阶段通常采用目录的部署方式，而在正式运行时通常把web应用打包为单个的.war文件进行方便地部署。也就是在你的应用目录（比如WebLogic的DefaultWebApp）下，执行下面的命令：
jar cf0 mywebapp.war **
这样，要部署到正式系统时就非常方便，只需要把这个.war文件拷贝到WebLogic的applications目录或Tomcat的webapps目录下即可自动进行部署。Tomcat会对部署的.war应用包进行自动监控、解包，所以不会出现下面提到的问题。而WebLogic并不会自动解包.war，所以如果在你的应用中，需要读取原来应用中的配置文件或其它资源文件时，就会发现，在解包部署时，正常运行的程序，在WebLogic中打包部署时，运行却出错，会报告找不到该文件。例如下面的应用：
|--DefaultWebApp |--index.jsp |--.....jsp |--WEB-INF |-- web.xml |-- log4j.properties |-- classes ......
其中使用到了Log4J作为日志输出工具，Log4J的配置文件log4j.propertes放在DefaultWebApp\WEB-INF目录下。Log4J通过一个自动加载的Servlet进行初始化，初始化代码如下：
ServletContext context = getServletContext();
org.apache.log4j.PropertyConfigurator.configure(context.getRealPath("/") +
"/WEB-INF/log4j.properties");
其中，context.getRealPath("/")得到当前Web应用的真实根目录，比如，如果你的WebLogic安装在D:\bea下，在Windows下context.getRealPath("/")通常会返回：
D:\bea\wlserver6.1\config\mydomain\applications\DefaultWebApp
在UNIX下类似：
/bea/wlserver6.1/config/mydomain/applications/DefaultWebApp
这样，和"/ WEB-INF /log4j.properties"拼接后，就得到了log4j.properties文件的真实路径，Log4J通过文件IO读取这个配置文件，完成初始化。
现在一切正常！测试通过后，将DefaultWebApp下的所有文件打为一个.war包，进行部署时，发现系统报告找不到“D:\bea\wlserver6.1\null\ WEB-INF \log4j.properties”文件！如果你的应用中还需要读取其它已经被打包到war包中的文件，都会报告找不到文件。并且，系统并不会到D:\bea\wlserver6.1\config\mydomain\applications\DefaultWebApp目录下寻找，而会到D:\bea\wlserver6.1\null下寻找。这是因为context.getRealPath("/")返回了null。查看ServletContext的API文档，
public String getRealPath(String path)
……
The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).
原来，对一个打包的应用来说，是没有RealPath的概念的，调用getRealPath只会简单地返回null。其实，也很好理解，一个文件被打包入了.war文件，就不存在目录结构了（虽然包中仍然存在目录结构，但这不等同于文件系统中的目录结构）。所以，对war包中的资源是无法得到RealPath的。这样也就无从通过文件IO进行读取了。那么，如何读取war包中的资源呢？答案是使用ServletContext.getResourceAsStream(String)方法。
对于org.apache.log4j.PropertyConfigurator，有如下几种配置方法：
static void configure(Properties properties);
static void configure(String configFilename);
static void configure(URL configURL);
既然，现在不能得到war包中的Log4J的配置文件，那么可以通过读入InputStream，构造一个Properties，通过configure(Properties properties)方法同样可以完成配置。示例代码如下：
InputStream is = getServletContext().
getResourceAsStream("/WEB-INF/log4j.properties");
Properties props = new Properties();
try {
props.load(is);
} catch (IOException e) {
System.err.println("Load log4j configuration failed");
}
PropertyConfigurator.configure(props);
那么，现在对于war应用可以成功运行，但如果现在不通过war部署，直接通过目录结构部署应用会不会又出现找不到资源的错误呢？请来看看ServletContext.getResourceAsStream的API文档，
Returns a URL to the resource that is mapped to a specified path. The path must begin with a "/" and is interpreted as relative to the current context root.
This method allows the servlet container to make a resource available to servlets from any source. Resources can be located on a local or remote file system, in a database, or in a .war file.
可见，通过getResourceAsStream可以获取包括本地文件系统、远程文件系统、war包等资源。不会出现上面担心的问题。
结论：在开发J2EE Web应用时，如果需要读取本应用中的文件，尽量使用ServletContext.getResourceAsStream进行，而不要使用文件IO。
二、Ant使用中的OutOfMemoryError解决
在开发大型项目时，类文件通常有数千个之多，这时都需要采用一些make工具来辅助开发。有时需要编译的类太多，使用Ant编译时，会出现OutOfMemoryError的错误，使编译进程中断。这时，通常通过先移出部分文件，分批编译。但Java编译过程的自动依赖编译，通常很难确定究竟应该先移出哪些文件、后移出哪些文件伤透脑筋。有没有简便的方法？有！
转到你的Ant的安装目录，在bin子目录中找到ant.bat，使用文字编辑器打开，修改:runAnt处的允许命令，添加如下参数：
:runAnt
"%_JAVACMD%" -Xms128m -Xmx512m -classpath ……
如果你安装了Jike，使用Jike编译器，则需要修改:runAntWithJikes处的运行命令，同上。
结论：Java虚拟机默认分配64M内存，如果你的应用比较大，超出64M内存，Java虚拟机就会抛出OutOfMemoryError，并停止运行。不管是什么应用（Web应用、Application等），只需要修改你的机器上的运行Java命令，在java xxx命令中添加-Xms(最小使用内存)、-Xmx（最大使用内存）即可解决。当然，这儿的内存容量都是指物理内存，不能超出你的机器的物理内存的总容量。