On Wed, 17 Jul 2002, Will Hartung wrote:
> 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.
>
Be sure you run some benchmarks before complaining too loudly about
"constantly grind through a jar file". You will find, for example, that
Tomcat will never do that more than once to load a class or JAR file, and
for most static resources in the WAR it will also unpack them once and
only once.
In the very large majority of cases, whether a webapp is unpacked or not
will have zero impact on performance for typical installations of Tomcat.
> 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).
>
As a matter of fact, Oracle has web containers that do exactly this --
funny thing, they run *faster* than the filesystem in many cases, because
they take advantage of the DBMS's optimized I/O and caching capabilities
:-).
> 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.
>
Not true.
File workdir = (File)
getServletContext().getAttribute("javax.servlet.context.tempdir");
You don't get any assurances about the persistence of any files you store
here, but this returns a perfectly useful directory for temporary files
that you might need to create during execution of your business logic.
(See section 3.7.1).
> 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.
>
That's one reasonable way to do it. All J2EE containers, by the way, need
to provide mechanisms for defining the values corresponding <env-entry>
resources.
> 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.
>
It is ... across every J2EE container.
> 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.
>
Well, there's always databases ... last I heard they are pretty good at
long term storage :-).
> 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])
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
