转载:关于war包中文件的读取(原创:bruce )
本文引自: http://fjy26.itpub.net/
war包中的文件的读取
在开发J2EE Web应用时,在开发阶段通常采用目录的部署方式,而在正式运行时通常把web应用打包为单个的.war文件进行方便地部署。也就是在你的应用目录(比如WebLogic的DefaultWebApp)下,执行下面的命令:
这样,要部署到正式系统时就非常方便,只需要把这个.war文件拷贝到WebLogic的applications目录或Tomcat的webapps目录下即可自动进行部署。Tomcat会对部署的.war应用包进行自动监控、解包,所以不会出现下面提到的问题。而WebLogic并不会自动解包.war,所以如果在你的应用中,需要读取原来应用中的配置文件或其它资源文件时,就会发现,在解包部署时,正常运行的程序,在WebLogic中打包部署时,运行却出错,会报告找不到该文件。例如下面的应用:
[pre] |--DefaultWebApp
|--index.jsp
|--.....jsp
|--WEB-INF
|-- web.xml
|-- log4j.properties
|-- classes
......[/pre]
其中使用到了Log4J作为日志输出工具,Log4J的配置文件log4j.propertes放在DefaultWebAppWEB-INF目录下。Log4J通过一个自动加载的Servlet进行初始化,初始化代码如下:
其中,context.getRealPath("/")得到当前Web应用的真实根目录,比如,如果你的WebLogic安装在D:bea下,在Windows下context.getRealPath("/")通常会返回:
D:beawlserver6.1configmydomainapplicationsDefaultWebApp
在UNIX下类似:
/bea/wlserver6.1/config/mydomain/applications/DefaultWebApp
这样,和"/ WEB-INF /log4j.properties"拼接后,就得到了log4j.properties文件的真实路径,Log4J通过文件IO读取这个配置文件,完成初始化。
现在一切正常!测试通过后,将DefaultWebApp下的所有文件打为一个.war包,进行部署时,发现系统报告找不到“D:beawlserver6.1null WEB-INF log4j.properties”文件!如果你的应用中还需要读取其它已经被打包到war包中的文件,都会报告找不到文件。并且,系统并不会到D:beawlserver6.1configmydomainapplicationsDefaultWebApp目录下寻找,而会到D:beawlserver6.1null下寻找。这是因为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,有如下几种配置方法:
既然,现在不能得到war包中的Log4J的配置文件,那么可以通过读入InputStream,构造一个Properties,通过configure(Properties properties)方法同样可以完成配置。示例代码如下:
那么,现在对于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。
war包中的文件的读取
在开发J2EE Web应用时,在开发阶段通常采用目录的部署方式,而在正式运行时通常把web应用打包为单个的.war文件进行方便地部署。也就是在你的应用目录(比如WebLogic的DefaultWebApp)下,执行下面的命令:
- jar cf0 mywebapp.war **
这样,要部署到正式系统时就非常方便,只需要把这个.war文件拷贝到WebLogic的applications目录或Tomcat的webapps目录下即可自动进行部署。Tomcat会对部署的.war应用包进行自动监控、解包,所以不会出现下面提到的问题。而WebLogic并不会自动解包.war,所以如果在你的应用中,需要读取原来应用中的配置文件或其它资源文件时,就会发现,在解包部署时,正常运行的程序,在WebLogic中打包部署时,运行却出错,会报告找不到该文件。例如下面的应用:
[pre] |--DefaultWebApp
|--index.jsp
|--.....jsp
|--WEB-INF
|-- web.xml
|-- log4j.properties
|-- classes
......[/pre]
其中使用到了Log4J作为日志输出工具,Log4J的配置文件log4j.propertes放在DefaultWebAppWEB-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:beawlserver6.1configmydomainapplicationsDefaultWebApp
在UNIX下类似:
/bea/wlserver6.1/config/mydomain/applications/DefaultWebApp
这样,和"/ WEB-INF /log4j.properties"拼接后,就得到了log4j.properties文件的真实路径,Log4J通过文件IO读取这个配置文件,完成初始化。
现在一切正常!测试通过后,将DefaultWebApp下的所有文件打为一个.war包,进行部署时,发现系统报告找不到“D:beawlserver6.1null WEB-INF log4j.properties”文件!如果你的应用中还需要读取其它已经被打包到war包中的文件,都会报告找不到文件。并且,系统并不会到D:beawlserver6.1configmydomainapplicationsDefaultWebApp目录下寻找,而会到D:beawlserver6.1null下寻找。这是因为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,有如下几种配置方法:
- staticvoid configure(Properties properties);
- staticvoid configure(String configFilename);
- staticvoid configure(URL configURL);
既然,现在不能得到war包中的Log4J的配置文件,那么可以通过读入InputStream,构造一个Properties,通过configure(Properties properties)方法同样可以完成配置。示例代码如下:
- InputStream is = getServletContext().
- getResourceAsStream("/WEB-INF/log4j.properties");
- Properties props = newProperties();
- 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。