tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: resource files not found in /WEB-INF/classes
Date Wed, 13 Feb 2002 04:14:42 GMT
See below.

On Tue, 12 Feb 2002, Michael Kintzer wrote:

> Date: Tue, 12 Feb 2002 18:56:38 -0800
> From: Michael Kintzer <MichaelK@ViAir.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: "Tomcat Users List (E-mail)" <tomcat-user@jakarta.apache.org>
> Subject: resource files not found in /WEB-INF/classes
>
> Tomcat 4.0.1: According to tomcat-docs/appdev/deployment.html,
> webapps/mywebapp/WEB-INF/classes/ is the appropriate location for any
> associated resource files required for an application "mywebapp".  I have
> placed a properties file "config.properties" in my /WEB-INF/classes/
> directory but when I try to access it using this code:
>
> package com.myco.myproj
>
> .. imports and other code...
>
> try
> {
> 	File f = new File("config.properties");
> 	FileInputStream fis = new FileInputStream(f);
> 	Properties prop = new Properties();
> 	prop.load(fis);
> }
> catch (Exception e)
> {
> 	e.printStackTrace();
> }
>
> I continually get java.io.FileNotFoundException: config.properties (The
> system cannot find the file specified).
>
> I even tried adding a context element in my conf/server.xml file for my web
> app like so:
>
> <!-- myproj context -->
> 	<Context path="/myproj" docBase="myproj" debug="0" reloadable="true"
> />
>
> but that had no effect.    I've searched through all the documentation I
> could find and it all seems to indicate that any resource files in
> /WEB-INF/classes should be detectable.  Any ideas on what I may be doing
> incorrectly would be greatly appreciated.
>
> Thanks,
>
>
> Michael Kintzer

There are two issues here that I'd like to address:

* How do I make File I/O work for this kind of thing?

* What's a more portable way to do this?

For the first answer, the thing you have to remember is that relative
pathnames like "config.properties" are resolved, by the file i/o routines
of Java or any other language, against the current working directory of
the application you are running (Tomcat, in this case).  You can't count
on *anything* about where that really is, because it depends on how Tomcat
is initially started (and which version you are running).  BUT, you can do
this right if you compute the path relative to the base directory of your
webapp, like this:


	File docBase = new File(getServletContext().getRealPath());
	File f = new File(docBase, "/WEB-INF/classes/config.properties");
	FileInputStream fis = new FileInputStream(f);

Will this work?  Yes -- but only sometimes.  What happens if you configure
Tomcat to run your webapp directly from a WAR file (or you need to migrate
to an application server that does not support running webapps from
unpacked directories)?  Then, you are in trouble, because getRealPath()
will return null.

There are two approaches that work just fine at this point:

* Use ServletContext.getResourceAsStream().  This call is guaranteed
  to work on any servlet container, regardless of how it internally
  represents your webapp:

	String path = "/WEB-INF/classes/config.properties";
	InputStream is =
	  getServletContext().getResourceAsStream(path);

  This call works because the context-relative path is resolved by
  the container -- and it's required to work in all circumstances.

  Note that you can even use this approach to read things like the
  web.xml file at run time, if you wanted to:

	InputStream is =
	  getServletContext().getResourceAsStream("/WEB-INF/web.xml");

  Struts needs to do this (as an example use case) because it needs to
  know what servlet mappings you are using, and there is nothing in the
  Servlet API that makes this information available to a webapp.

* The fact that you are willing to put this file into the /WEB-INF/classes
  subdirectory means that you can rely on a similarly-named method
  provided by the JDK:

	String path = "config.properties";
	InputStream is =
	  this.getClass().getClassLoader().getResourceAsStream(path);

  This call works because it uses the capability of JDK class loaders
  to find resources that are included in the class path of your web
  application -- even if they are inside a JAR file.  It is particularly
  useful for configuring class libraries that might also be used outside
  of a web application environment, but it works here as well because the
  "/WEB-INF/classes" directory is always made visible to the class loader
  for your web application.

Bottom line: *****PLEASE***** avoid the use of file I/O to access
resources inside your web applications.  This is only going to cause you
portability grief later on.  You should get in the habit, from the very
beginning, of using the APIs that are made available to access
inside-the-webapp resources in a portable way.

Craig McClanahan



--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message