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.

-----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