[EMAIL PROTECTED] wrote:
For web applications, containers are required to provide an
application-scoped temp directory (private to the individual app).  Not sure
if this was available in servlets 2.2, but it's here in 2.3, and is, in my
opinion, a better default than the global io temp directory.

SRV.3.7.1 Temporary Working Directories
A temporary storage directory is required for each servlet context. Servlet
containers must provide a private temporary directory per servlet context,
and make
it available via the javax.servlet.context.tempdir context attribute. The
objects
associated with the attribute must be of type java.io.File.
The requirement recognizes a common convenience provided in many servlet
engine implementations. The container is not required to maintain the
contents of
the temporary directory when the servlet container restarts, but is required
to
ensure that the contents of the temporary directory of one servlet context
is not
visible to the servlet contexts of other web applications running on the
servlet
container.


This is in servlets2.2 too, but less specified.

"All servlet containers must provide a private temporary directory per servlet context and make it available via the context attribute of javax.servlet.context.tempdir. The object associated with the attribute must be of type java.io.File."

I am in favour of using the tempdir ahead of all others. We'd probably have to modify the SimpleServer to set the property.

There is stuff in the code to handle missing directories, missing write access and have fallbacks and things. IMO if we use the ${javax.servlet.context.tempdir} value and just probe it for writeability; if it isnt writeable then we have a config error and should bail out.

Also: we do still need to support no-servlet operation' I was looking at the jabber transport yesterday, for example.


-----Original Message----- From: Jens Schumann [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 9:51 AM To: [EMAIL PROTECTED] Subject: Attachment Destination - Default tmp filepath


Right now axis assumes that context.getRealPath(...) returns a writeable path for storing attachments and its server-config.wsdd. In production the server-config isn't a problem, but for attachments we should use a different default behavior:

1. Default location for attachments should be outside of the war archive, I
recommend System.getProperty("java.io.tmpdir").

2. A user may override this behavior in service-config.wsdd using <parameter
name="attachments.Directory" value="somedir"/>.

The Axis Runtime should not generate this service-config.wsdd entry, because
this removes the axis deployment destination independency. Just imagine that
you want to deploy your axis configuration with your .ear or .war and have
several deploy destinations (local testing per user, pre production,
production system).


Any comments?


Jens




Reply via email to