Enabling any Java application for use with RTI comes down to augmenting the JVM command-line options and property definitions. There are many different ways of launching a JVM and we have tried to automate the most common way using the "rti edit" mechanism described above. However, if you are not relying on the normal "standalone.sh/bat" startup mechanism of newer JBoss versions, or are using a Java service wrapper, or are using Fuse, the "rti edit" mechanism won't work. Instead you will need to edit your JBoss, Fuse or service wrapper configuration file directly. Some more common mechanisms are described in the following sections. If the mechanism you are using does not appear here, you can probably figure it out by looking at one of these. If not, please contact us.

Warning

This procedure uses XML configuration elements that only work on JBoss AS7.1 and above. Specifically, a bug in AS7.0.1 with <jvm-option> elements prevents this procedure from working.
In the simplest case, this means modifying the file domain/configuration/host.xml. In more complex situations, the JVM definition used for JBoss server instances may be in some other XML configuration file. It is important that you understand the JVM definition structure for your site so that you can add the RTI-specific options to the correct JBoss servers JVM definitions.
Below is an excerpt from a host.xml file showing the RTI-specific options:
<?xml version='1.0' encoding='UTF-8'?>

<host name="master" xmlns="urn:jboss:domain:1.5">

[...SNIP...]

 	<jvms>
 	  <jvm name="default">
          <heap size="64m" max-size="256m"/>
          <permgen size="256m" max-size="256m"/>
          <jvm-options>
              <option value="-server"/>
               
              <option value="-agentpath:/opt/rti_home/lib64/libspjagent.so=init=jboss.ini"/>
              <option value="-Drti.home=/opt/rti_home"/>
              <option value="-Drti.app.type=jboss"/>
              <option value="-Drti.app.home=/opt/jboss-eap-6.2"/>
              <option value="-Djboss.modules.system.pkgs=com.windriver"/>
              <option value="-Dspj.temp.directory=/opt/rti_data/tmp"/>
              <option value="-XX:-UseSplitVerifier"/>
          </jvm-options>
      </jvm>
 	</jvms>

    <servers>
        <server name="server-one" group="main-server-group">
            <jvm name="default">
              <jvm-options>
                  <option value="-Drti.collector.id=jboss_server-one"/>
              </jvm-options>
           </jvm>
        </server>
    </servers>

[...SNIP...]

Of course, your installation paths and server names will be different: /opt/rti_home will be replaced by your value for $RTI_HOME, /var/rti_data by $RTI_DATA and /opt/jboss-eap-6.2 would be your $JBOSS_HOME value. Similarly, "server-one" and "main-server-group" and the name you choose for rti.collector.id will probably be different. See below for more detailed descriptions of the RTI-specific options.
Note that as shown above the common options are in the common JVM extension and the collector id definition is in the individual server JVM extensions. This allows you to have a separate collector for each server instance in the group (your cluster). Alternately, you can have all instances share the same collector by moving the rti.collector.id definition up to the common options.
This JVM definition applies to all servers defined in this host.xml file. In this case the whole <jvm-options> element has been added. Your site definition may contain other<option> elements, in which case you should just add the RTI-specific <option> elements to the <jvm-options> element.
The RTI-specific <option> elements are:
The process of adding JVM parameters to the configuration file is simple, but you should understand the Fuse service wrapper configuration for your site.
Below is an excerpt from a modified Fuse service wrapper configuration file, $FUSE/etc/ServiceName-wrapper.conf (where ServiceName is the name you give to your Fuse service):
[...SNIP...]

# JVM Parameters            
# note that n is the parameter number starting from 1.
wrapper.java.additional.1=-Dkaraf.home=%KARAF_HOME%
wrapper.java.additional.2=-Dkaraf.base=%KARAF_BASE%
wrapper.java.additional.3=-Dkaraf.data=%KARAF_DATA%
wrapper.java.additional.4=-Dcom.sun.management.jmxremote
wrapper.java.additional.5=-Dkaraf.startLocalConsole=false
wrapper.java.additional.6=-Dkaraf.startRemoteShell=true
wrapper.java.additional.7=-Djava.endorsed.dirs=%JAVA_HOME%/jre/lib/endorsed:%JAVA_HOME%/lib/endorsed:%KARAF_HOME%/lib/endorsed
wrapper.java.additional.8=-Djava.ext.dirs=%JAVA_HOME%/jre/lib/ext:%JAVA_HOME%/lib/ext:%KARAF_HOME%/lib/ext

wrapper.java.additional.9=-agentpath:/opt/ocsystems/rti/ee64/lib64/libspjagent.so=init=fuse.ini
wrapper.java.additional.10=-Drti.app.type=fuse
wrapper.java.additional.11=-Drti.home=/opt/ocsystems/rti/ee64
wrapper.java.additional.12=-Drti.app.home=%KARAF_HOME%
wrapper.java.additional.13=-Drti.collector.id=fuse_XXXXXX
wrapper.java.additional.14=-Dspj.temp.directory=/var/opt/ocsystems/rti/ee64/tmp
wrapper.java.additional.15=-XX:-UseSplitVerifier

[...SNIP...]

Of course, your installation paths and server names will be different: /opt/ocsystems/rti/ee64 will be replaced by your value for $RTI_HOME (in two places), and /var/opt/ocsystems/rti/ee64 by $RTI_DATA.  Also you will need to replace fuse_XXXXXX with a better name for your RTI collector.

Note

The numeric suffixes of the "wrapper.java.additional.nn" properties should be sequential and follow any suffixes you have locally--we used 9 through 15 for this example.
The RTI-specific JVM parameters are::
  • -agentpath:[path-to-RTI-agent-library]=init-fuse.ini
    This is the RTI agent library loaded into the JVM, Specify the correct path to the appropriate library to be loaded in the JVM, which means the host architecture and bit size must match. For 32-bit JVMs use the path [RTI-installation]/lib and for 64-bit JVMs use the path [RTI-installation]/lib64. The path should not contain spaces (on Windows use 8.3 equivalents). The actual agent library name is libspjagent.so on Linux and libspjagent.dll on Windows. The above example is from a typical Linux RTI installation.
  • -Drti.home=[path-to-RTI-installation]
    This defines the path to the RTI installation. Specify the path to your RTI installation. The path should not contain spaces (on Windows use 8.3 equivalents).
  • -Drti.app.home=%KARAF_HOME%
    This defines the path to the Fuse installation. We used the pre-defined KARAF_HOME variable.
  • -Drti.app.type=fuse
    This defines the RTI application type, in this case a Fuse server.
  • -Drti.collector.id=fuse_[server-name]
    This defines the RTI collector name to be used to control data collection and storage. Specify the name you want to use. The RTI convention is to use the "fuse_" prefix for Fuse collectors, and to uniquely identify the configuration, profile or server for which RTI is collecting data.
  • -Dspj.temp.directory=/var/opt/ocsystems/rti/ee64/tmp
    This option specifies where the RTI temp directory should be located. The normal default is $RTI_DATA/tmp, with the path fully specified.
  • -XX:-UseSplitVerifier
    This option prevents the Java 7 JVM from failing on RTI-instrumented Java byte-code.
Also, you must edit the file $FUSE/etc/config.properties to add RTI classes to the bootdelegation list. This allows the RTI classes to collect information from the Fuse server. If your site contains other values, then add the RTI-specific com.windriver.sensorpoint to the list, separated by a comma. (This may already be done if you used rti edit -t fuse.) The following is an example of that change (with no embedded line breaks or spaces):
org.osgi.framework.bootdelegation=org.apache.karaf.jaas.boot,sun.*,com.sun.*,
  javax.transaction,javax.transaction.*,org.apache.xalan.processor,
  org.apache.xpath.jaxp,org.apache.xml.dtm.ref,org.apache.xerces.jaxp.datatype,
  org.apache.xerces.stax,org.apache.xerces.parsers,org.apache.xerces.jaxp,
  org.apache.xerces.jaxp.validation,org.apache.xerces.dom,com.windriver.sensorpoint 

Note

Refer to this document for more about generating Fuse server wrappers.
First, identify where your service wrapper configuration file is, then determine how you add additional JVM parameters (not application parameters) for that service wrapper. Your application may require some additional JVM parameters of its own, so make sure you preserve them when adding the RTI JVM parameters.
A typical format for service wrapper configuration files follows (this is Fuse):
[...SNIP...]

# JVM Parameters            
# note that n is the parameter number starting from 1.
wrapper.java.additional.1=-Dkaraf.home=%KARAF_HOME%
wrapper.java.additional.2=-Dkaraf.base=%KARAF_BASE%
wrapper.java.additional.3=-Dkaraf.data=%KARAF_DATA%
wrapper.java.additional.4=-Dcom.sun.management.jmxremote
wrapper.java.additional.5=-Dkaraf.startLocalConsole=false
wrapper.java.additional.6=-Dkaraf.startRemoteShell=true
wrapper.java.additional.7=-Djava.endorsed.dirs=%JAVA_HOME%/jre/lib/endorsed:%JAVA_HOME%/lib/endorsed:%KARAF_HOME%/lib/endorsed
wrapper.java.additional.8=-Djava.ext.dirs=%JAVA_HOME%/jre/lib/ext:%JAVA_HOME%/lib/ext:%KARAF_HOME%/lib/ext

wrapper.java.additional.9=-agentpath:/opt/ocsystems/rti/ee64/lib64/libspjagent.so=init=fuse.ini
wrapper.java.additional.10=-Drti.app.type=fuse
wrapper.java.additional.11=-Drti.home=/opt/ocsystems/rti/ee64
wrapper.java.additional.12=-Drti.app.home=%KARAF_HOME%
wrapper.java.additional.13=-Drti.collector.id=fuse_XXXXXX
wrapper.java.additional.14=-D rti.app.cfg=profile_PPPPPPP
wrapper.java.additional.14=-Dspj.temp.directory=/var/opt/ocsystems/rti/ee64/tmp
wrapper.java.additional.15=-XX:-UseSplitVerifier

[...SNIP...]

In this case, the additional RTI parameters are added as additional "wrapper.java.additional.NN=value" name-value pairs.   Of course, your installation paths and server names will be different: /opt/ocsystems/rti/ee64 will be replaced by your value for $RTI_HOME (in two places), and /var/opt/ocsystems/rti/ee64 by $RTI_DATA.  Also you will need to replace fuse_XXXXXX with a better name for your RTI collector, and profile_PPPPPP with your server profile (see below) . 
Note that in some instances you will need to increase the timeout value of the service wrapper, because RTI initialization may delay your application start up. See your service wrapper documentation for information about this.
The RTI-specific JVM parameters are:: 
  • -agentpath:[path-to-RTI-agent-library]=init-fuse.ini
    This is the RTI agent library loaded into the JVM. Specify the correct path to the appropriate library to be loaded in the JVM, which means the host architecture and bit size must match. For 32-bit JVMs use the path [RTI-installation]/lib and for 64-bit JVMs use the path [RTI-installation]/lib64. The path should not contain spaces (on Windows use 8.3 equivalents). The actual agent library name is libspjagent.so on Linux and libspjagent.dll on Windows. The above example is from a typical Linux RTI installation.
  • -Drti.home=[path-to-RTI-installation]
    This defines the path to the RTI installation. Specify the path to your RTI installation. The path should not contain spaces (on Windows use 8.3 equivalents).
  • -Drti.app.home=%KARAF_HOME%
    This defines the path to the Fuse installation. We used the pre-defined KARAF_HOME variable.
  • -Drti.app.type=jboss
    This defines the RTI application type, in this case a Fuse server.
  • -Drti.collector.id=jboss_[server-name]
    This defines the RTI collector name to be used to control data collection and storage. Specify the name you want to use. The RTI convention is to use the "fuse_" prefix for Fuse collectors, and to uniquely identify the configuration, profile or server for which RTI is collecting data.
  • -D rti.app.cfg=jboss_[server_profile or server-config name]
    This option is required for JBoss servers.  If your JBoss version is EAP 5 (AS 6) or earlier, this value should be the server profile value (the value normally passed with "-c" option).  If your JBoss version if EAP 6/AS 7/WildFly 8 or later, this value should be the full path to the server configuration file (normally passed with the "--server-config" option). (Since 3.4.6)
  • -Dspj.temp.directory=/var/opt/ocsystems/rti/ee64/tmp
    This option specifies where the RTI temp directory should be located. The normal default is $RTI_DATA/tmp, with the path fully specified.
  • -XX:-UseSplitVerifier
    This option prevents the Java 7 JVM from failing on RTI-instrumented Java byte-code.
You may find it helpful to look at the RTI scripts used to do this for non-server wrapper applications. Look in RTI_HOME/bin/rti_enable_XXXX.sh/bat for more examples.


loading table of contents...