From: Guijarro, Julio <julio_guijarro@hp...> - 2004-07-26 16:19:45
See my comments bellow.
> Hello all,
> Ritu and I have been dealing with the problem of how to include
> user-specific customisations into
> daemons deployed during testing.
> The current case of this is how to configure the runtime to locate
> jetty, but there are clearly other examples -anywhere where we need to
> let individual developers point the daemons at part of the system.
> Support for such overrides is inherent with the PROPERTY and LAZY
> PROPERTY attributes of the language, but we still need to set up the
> jvms with customised properties.
> We support customisation within ant by having support for an optional
> core/build.properties file that overrides ant properties for a build.
> I'd like to do something similar with the daemon. Here is the proposal
> 1. we have an (optional) file in the core directory called
> 2. this file is (optionally) loaded when we come to deploy.
What you are describing here is "default.ini".
- Optional: defined with: -Dorg.smartfrog.iniFile=...
- It is loaded for ever Process JVM)
> 3. Everywhere that we start a daemon or deploy, we load in this common
> property file.
It is treated as another resource and it can be dynamically loaded from a
remote location. It is loaded using the SF classloader.
Reminder, with security on, default.ini is loaded from a signed jar file.
> 4. Everyone who hard codes paths into their test/demo scripts stops it
> and uses this option.
It will overwrite any predefined properties.
> One other point to note is the cross platform problem: you cannot have
> use normal string operations to create and manipulate portable file
> paths, which makes it very hard to do cross-platform deployment
> descriptors. There is a File component in services/OS that can be set up
> with a file, and which adds the attribute absolutePath to itself on
> deployment...this path is platform specific, even if the directories and
> files used as parameters, are written with forward or backward slashes.
> To get (3) working I will have to extend the ant tasks; there isnt
> something built in to ant that meets our needs, either. Its a pretty
> simple addition; expect it later today.
We need to make this generic. We should use an object for Paths that would
be cross platform.
Last week I modified ProcessCompound so that the properties passed to
SubProcesses can be customized.
Any property prefixed by
'org.smartfrog.sfcore.processcompound.jvm.'+NAME+.+property=value will be
added only to the subprocess named 'NAME' as a parameter for the JVM. The
parameter will be "property+value".
* will add the property '-Xrunpri' to the ProcessCompound named 'test'.
These properties can be placed in the command line or in default.ini.