Java-SJ
view release on metacpan or search on metacpan
You may be wondering how SJ figures out which is the 'latest'
version of a JAR file if no version is specified. Quite simply it
chooses the one whose filename begins with the required name and is
lexicographically last in an ordered list of those filenames that
match. It's not great but with any half-sensible version numbering
scheme it will work.
Virtual Machines
There are four virtual machines defined here. In addition to the
home directory for each there is now information regarding the
vendor and version. Currently this is for informational purposes
only but future versions of SJ should be able to choose a VM based
on the version or vendor.
<?xml version="1.0"?>
<sj>
<!-- define the class file to run -->
<class>myclass</class>
<vm ref="blackdown118"/>
</sj>
<?xml version="1.0"?>
<sj>
<!-- define the class file to run -->
<class>myclass</class>
<vm ref="ibm118"/>
</sj>
<?xml version="1.0"?>
<sj>
<!-- define the class file to run -->
<class>myclass</class>
<vm ref="sun131"/>
</sj>
The above application configurations are exactly the same as the simple
version with the addition of a vm reference tag to determine which VM
they should be executed under.
High Granularity
In addition to being able to specify which VMs and libraries to use you
have complete control over the environment that the VM is run under, the
properties that are passed the the VM and even default command line
options on a per system, VM and application basis.
<?xml version="1.0"?>
<sj>
<!-- important locations -->
<var name="dir.base" value="/usr/local"/>
<var name="dir.pid" value="${dir.base}/var/run"/>
<var name="dir.log" value="${dir.base}/var/log/sj"/>
<var name="dir.tmp" value="/tmp"/>
<var name="dir.lib" value="${dir.base}/lib/sj"/>
<var name="dir.script" value="${dir.base}/var/sj/script"/>
<!-- add these as -Dname=val VM properties-->
<property name="ORBSingletonClass" value="jacorb.ORBSingleton"/>
<!-- add these to the environment for every app -->
<environment name="TZ" value="CET"/>
<environment name="PAGER" value="less"/>
<!-- add these to the command line parameters of every app -->
<param name="--debuglevel" value="3"/>
<param name="--colour" value="blue" sep="="/>
<param name="-g" value="3" sep=":"/>
<!-- write out a PID file for every program -->
<pid/>
<!-- use this as our default CLASSPATH -->
<classpath>
<jar name="xalan"/>
<jar name="xerces"/>
<jar name="xml-apis"/>
<jar name="commons-cli" version="1.0.3"/>
</classpath>
<vm name="ibm118"
vendor="IBM"
version="1.1.8"
home="/usr/local/IBMJava-1.1.8">
<!-- set USE_JIT whenever this VM is chosen -->
<environment name="USE_JIT" value="true"/>
</vm>
<vm name="ibm141"
vendor="IBM"
version="1.4.1"
home="/usr/local/IBMJava-1.4.1"/>
<vm name="blackdown118"
vendor="Blackdown"
version="1.1.8"
home="/usr/local/blackdown-1_1_8">
<!-- set this parameter for this VM only -->
<param name="-Xmx" value="81920k" sep=""/>
</vm>
<vm name="sun131"
vendor="Sun Microsystems"
version="1.3.1"
home="/usr/local/sunjdk_131"
default="true"/>
</sj>
The above system configuration is identical to our useful configuration
except we have now added directives that SJ will use to alter the
environment and command line parameters passed to the application and
VMs.
Using VM specific parameters you can make sure that the correct
threading models are used or that memory limuts are enforced unless
someone needs to tweak the settings.
In an application configuration file it is possible to override
previously declared parameters such as the -Xmx directive above for the
blackdown VM.
For example:
( run in 2.328 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )