Running the command executor

The binary distribution of quExec contains a jar with all necessary dependencies. The class

  net.sourceforge.quexec.main.OSCommandExecutor

bundles the main functionality of quExec.

The bin-directory contains a simple start script that should be easy to adapt to your environment. With this start script you can start the OSCommandExecutor simply by executing

  ./bin/quExec.sh <options>

If you want to start the JVM directly, you can do so as follows:

  java -cp quExec-0.3-jar-with-dependencies.jar \
    net.sourceforge.quexec.main.OSCommandExecutor -h

In addition to that jars for the JMS provider will be needed in the $CLASSPATH. The lookup of JMS destinations is based on JNDI and a corresponding jndi.properties file should exist in the $CLASSPATH such that the initial JNDI context can be resolved.

For example, a quExec server process using ActiveMQ may be started like this:

  java -cp \
    conf/activemq:$ACTIVEMQ_HOME/activemq-all-5.2.0.jar:target/quExec-0.3-jar-with-dependencies.jar \
    net.sourceforge.quexec.main.OSCommandExecutor

In this example, the directory conf/activemq contains the jndi.properties file. This directory is contained in the distribution of quExec and can be used for tests against the standard ActiveMQ test environment that is configured with quExec (see below).

Running the command executor with Maven (for testing)

An easy way to execute a Java main program with a classpath that includes all dependencies for testing is to use the Maven exec-plugin, e.g.,

  mvn exec:java \
    -Dexec.mainClass=net.sourceforge.quexec.main.OSCommandExecutor \
    -Dexec.args="ls /"

mvn exec:java launches the given Java class with all test-level dependencies that are specified in the Maven pom. In particular, this includes ActiveMQ jars. Thus, this way of launching quexec is self-contained. In particular, the $CLASSPATH does not need to contain references to a JMS environment.

See below how to start the ActiveMQ message broker.