From: David Tolpin (dvd@renderx.com)
Date: Mon Oct 28 2002 - 05:14:10 PST
> > All properties have corresponding variables and a way to set them; setting
> > properties is however a good way to change things. They do not interfere with
> > other system properties since all of them belong to com.renderx.xep domain.
>
> But they do interfere with each other. In an application server many applications
> can run in the same JVM. These applications must at all times be independent of
> each other. If two of such applications want to use XEP with different options,
> they can't if options must be passed as system properties. A particular property
> can have only one value.
None of the options that may be required to set differently within one VM are
in fact set by environment variables. Everything you may want to set differently for
different threads of XEP can be set using API variables and calls.
System properties are for providing DEFAULT values. Exactly the same way as, for example,
org.xml.sax.parser.
> There may be several application server instances running on the same machine and
> several may be using XEP. These servers can't be managed independently if one must
> keep a global view of which server uses which temporary directory. In a data centre
> environment it is not even always known where a server instance ends up, because of
> fail-over mechanisms. Only if a global file system is available, as a SAN for example,
> different absolute paths can be configured for the temporary directories, which are
> visible and equal on all machines. It is, however, much simpler to say just once
> that the temporary directory is, say, /tmp. This will always work, no matter where
> the application server runs.
Werner,
I do know what I am against.
A unique file name across JVM boundaries cannot be generated without going beyond Java API.
At the same time, from the servers' point of view, it is easy to pass a unique directory
name, based, say, a process identifier in Unix or a counter to each particular instance of XEP.
The thing is not that I don't know how to create unique file names, but that I do instist
on separation of abstractions for clarity of interfaces. If there is no consistent way in Java API
to generate unique file names across JVM boundaries, then users of XEP should not rely on it
and should use OS calls to do it instead.
>
> On the command-line there could also be a problem if several users log in on a UNIX
> machine and run XEP. They would have to know that they shouldn't use /tmp, which is
> the general temporary directory.
Generating temporary files in tmp for application programs in a multi-user machine is
a bad practice anyway and is a source for many security risks. On the other hand,
simply wrapping XEP in a script that looks like:
#!/bin/sh
TMPDIR=/tmp/xep/$USER/$$
mkdir -p $TMPDIR
java -Dcom.renderx.xep.TMPDIR=$TMPDIR com.renderx.xep.Driver $*
rmdir $TMPDIR
I may oversimplify things a bit, but I would like to underline that providing
separate temporary directory for each user and/or JVM is a system administration
task.
>
> In practice generating unique filenames would solve the problem.
There is no solution to the problem of generation of unique file names within Java API across
JVM boundaries.
David Tolpin
-------------------
By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST