Getting absolute path in runtime for file declared in classpath

[Ashraf Fouad]

Dear all,
I have a small problem retrieving the absolute path of a file defined in the classpath, I use the following code in my static initializer:
static {
URL l_Url = ClassLoader.getSystemClassLoader().getResource( "/properties/a.properties" );
}
Part of my application runs as a web application & I place this file in WEB-INF/classes folder, and the other part of the application runs as batch process and the file is placed in the classes folder defined in classpath.
The problem is when I run the part of the code that works as batch the code runs smoothly & l_Url returns with the full path of the file and I can get it using l_Url.getFile()
but when I run the part as webapplication l_Url is always returned with null so I can't find the file.
I don't know what is the problem specially I use ResourceBundle in getting other files in the classpath and it works fine which mean that the classpath is working ok.
but the problem of the first file, I want to get its absolute path not its content to pass it to another module.
so any ideas

[Tim Holloway]

You're making the assumption that the webapp can only be loaded from a file system.
For many appservers that might be the case, but it isn't an architectural requirement. All that's eally required is that the classes (and info in the class context) be supplied by some sort of classloader. That classloader might be based on a network connection or it might be a mechanism that selects different file locations based on the user's local or security or something. Or the classes might een come from a chunk of flash RAM using a custom JNI class source.
Because of this - and to discourage the creation of webapps what are non-portable to to dependency on hard-coded file locations - many appservers don't provide file information that can't be guaranteed meaningful in all contexts.
You can retrieve data via a resource reference, but in a webapp, the only safe way to refer to absolute file locations is to pass them in via configuration parameters.

[Ashraf Fouad]

Thankx for yr reply ...
I understand what u said, but I think that there must be a guaranteed way in Java specs to locate files in the file system.
So the real help will be supplying another way to these files.

[Joel McNary]

It depends on how you want to use the files.

InputStream aStream = ClassLoader.getSystemClassLoader().getResourceAsStream( "/properties/a.properties" );

will get the contents of the file as an InputStream. Perhaps your other modules could use the stream? Don't know if this helps, but its an option (and how I read files from my webapps).

[David O'Meara]

and yet another opinion...
The files that can be found by a ClassLoader depend on which ClassLoader you use to find the resource. The sample code given assumes that the resource can be found using the boot ClassLoader or a near neighbour.
In a web app, given a class that exists in the web application, you can get the ClassLoader for it and use that ClassLoader to load resources from the web-inf/classes directory.
eg if the class my.package.MyClass is in the directory web-inf/classes/my/package/, then you can find the file web-inf/classes/a.properties using

URL l_Url = my.package.MyClass.class.getSystemClassLoader().getResource( "/a.properties" );

[Tim Holloway]

Notice the common thread here. Classes don't have to come from a file - it's even possible for a program to dynamically create a class on the fly by building up binary bytecodes in memory or to an output stream (which is not the same thing as a file).
This is why you can find no support for actually getting the file objects themselves. The environment cannot assume that file objects even exist. You can get the file contents by reading them as resource streams. Just not the files.
If you need to store stuff in files so you can manipulate actual file objects, it's more portable to store them independently of the web app. This also separates the web app from the data, which is almost always preferable, since most of the time the data will change more frequently than the web app will.