From: "Paul Phillips" <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 5:20 PM
Subject: io path information in servlets
> I have a webapp that stores some data in an xml file. (I am using jdom to
> read and write the xml files.)
>
> Right now I am using a construct like:
>
> String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
>
> to get the path. I then concatonate that with the file name and it works
> fine.
>
> However, in the javadocs for javax.servlet I read:
>
> "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)."
>
> I am not exactly sure what this means. If I deploy this application as a
> .war, does the sc.getRealPath stop working?
What it is refering to is the fact that there is nothing in the
specification that says when a WAR is deployed into a server, that the WAR
is actually exploded into something resembling a filesystem, much less
something that you may actually have write access too (or, heck, even READ
access for that matter).
It has CONVENTIONALLY been done this way, as it's a fairly obvious
optimization to handle a web app (who wants to constantly grind through a
jar file for crying out loud). However, what is convention, and what is
specification are two completely different things.
So, specifically, if you are relying upon the fact that getRealPath will
give you a location that you can actually perform read/write file I/O upon,
then you are relying on a Container specific behavior that MAY not be
portable to other containers.
A simple contrived example is that if you were deploying your WAR to, say,
an Oracle Application Server, then Oracle can easily "deploy" the WAR into
DBMS Tables and not use a file system at all, and this behavior is perfectly
legal within the specification. (Mind you, I don't know what Oracle does.
Like I said, a contrived example).
Another example is that your WAR may be deployed into a container where the
webapp is exploded in an area where you may only have READ permission, and
not WRITE. Also legal.
It's actually a bit of a nit of mine that by specification, there is no
guaranteed, portable way for a Servlet to get access to some writeable area
for file I/O. It can be a parameter, say in the WAR, but the container
itself is not guaranteed to have to deliver this kind of functionality to a
Servlet.
I think that for PORTABILITY, you should make the path that you save your
XML file to be a ENV-ENTRY in the WAR, that, at least in TC 4, can be
overridden by the Context that deploys the WAR. This gives the person
deploying your application the control over where your webapp can write to
its disk.
For those containers that do not have the ability to override the ENV-ENTRY
in the Context, they're stuck unpacking the WAR and fixing it there (so much
for validating the integrity of your WAR buy signing it, though to be honest
I don't know if the specification mentions anything about signed WARs).
Which is another nit. Something like the ENV-ENTRY override needs to be
standardized.
Also, if you're writing stuff to the "exploded webapp directory", then
remember that it can "go away" if the container, for whatever reason,
decided to redeploy your WAR.
Basically, what you're doing with TC is probably fine, even semi-long term,
but it's not portable behavior as documented in the specification.
These limitations are not there specifically to screw up your code, they're
in the spec to let the container developers have a lot more flexibility in
how they build their containers.
Best Regards,
Will Hartung
([EMAIL PROTECTED])
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
