view release on metacpan or  search on metacpan

lib/Java/SJ.pm  view on Meta::CPAN

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.

=item 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.

=back

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

=head2 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:

	<?xml version="1.0"?>