From: Werner Donné (werner.donne@re.be)
Date: Mon Oct 28 2002 - 04:57:02 PST
David,
>>2) Is there another way in the API to set the options than through system
>> properties? This is important because an application normally doesn't
>> have access to the system properties of the JVM running the application
>> server. It would also make the options global for the JVM. They would act
>> as global variables. This would make it impossible, for example, to choose
>> between PDF and PostScript depending on the request. Ideally the options are
>> passed through the stack.
>
>
> 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.
>>3) The user guide says in the description of the TMPDIR option that each JVM
>> must have its own tmp directory. Can I conclude from this that the
>> generated filenames are not unique? In an application server environment
>> this would be difficult to manage. Potentially two versions of XEP are
>> present in the system, because different applications use it but can't all
>> upgrade at the same time. One application must not impose a test cycle on
>> the others only because it needs an upgrade.
>> In J2EE this is solved very naturally by including the components in the ear
>> file, instead of installing them globally. Applications are insulated from
>> each other. A unique TMPDIR per JVM would make this impossible.
>
>
> I don't understand this point. If you run two different copies of XEP, then you have
> two different installations of XEP, each with a separate ROOT and configuration file.
> In the same way you can specify a different temporary directory for each installation.
> Please describe your problem. I cannot imagine a case when a separate temporary directory
> for each running Java Virtual Machine may be a problem.
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.
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.
In practice generating unique filenames would solve the problem.
Werner.
-- Werner Donné -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be ------------------- 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