On Mon, 26 Mar 2001, [iso-8859-1] Endre St�lsvik wrote:
>
> Thanks for fast reply!
>
> On Sun, 25 Mar 2001, Craig R. McClanahan wrote:
>
> | Could you try this with a recent nightly build? There have been lots of
> | bug fixes since 4.0b1 (we're about to roll a 4.0b2 if you want to wait a
> | couple of days).
>
> I'll do that, sometime later today, I hope..
>
> |
> | However, your code is making an assumption that is not portable. Servlet
> | containers are *not* required to unpack your application into a directory
> | structure, so there is no guarantee that there will be such a thing as a
> | File that you can read. The portable way to open this resource would be:
> |
> | InputStream is =
> | DOMConfigurator.class.getResourceAsStream("log4j.dtd");
>
> This file is already within a jar, it's the apache log4j package, still in
> a jar. As I remember, this is just ripped from Ceki's "man pages" for
> log4j..
The code you presented tried to open the properties as a
java.io.FileInputStream, which will only work if the servlet container
runs your webapp in an unpacked dirctory structure.
The suggestion above will work if the resource is inside or outside a JAR,
and whether the servlet container unpacks or does not unpack the webapp.
> Is that what you meant, that you cannot load from the jar (war)? Why
> will it work better if you get it as a Stream? What will happen when I
> package a bunch of jars inside a war, will it still be possible to get to
> this log4j.dtd whcih is within the jar which is within the war?
>
> Also, I have to do this .. :
>
> URL configURL =
> DOMConfigurator.class.getClassLoader().getResource(Settings.getLOG_CONFIG_FILE());
>
> .. with the getClassLoader() in place there. If not, I don't get the URL,
> it returns null. Why is that? I thought that the Class would itself just
> do exactly that, do a "getClassLoader().getResource()" .. This works out
> the same way if I instead of DOMConfigurator put Startup, which is the
> "residing class" itself..
>
The difference between Class.getResource() and
ClassLoader.getResource() is annoying but real. It has to do with the
type of path that you specify as a string argument. I tend to use the
getClass() version myself, to take care of the following type of scenario:
* My class is in a package (say, com.mycompany.mypackage)
* My properties file is in the same package (i.e. the MyProps.properties
file ends up in the same place that MyClass.class does)
Now, I can write the following in MyClass:
URL propsURL =
this.getClass().getResource("/com/mycompany/mypackage/MyProps.properties");
or
InputStream is =
this.getClass().getResourceAsStream("/com/mycompany/mypackage/MyProps.properties");
>
> --
> Mvh,
> Endre
>
>
>
Craig
