UG 5 EJBs

5 Writing an EJB-enabled JTR-Runner

If you have already grasped all the basic ideas and APIs behind writing a simple JSE JTR-Runner, it is not going to be hard learning how-to write an EJB-enabled JTR-Runner.

Basically you still have to inherit from jtr.runners.AbstractRunner, and leverage on both a properly edited jtr.xml configuration file and the jtr.enterprise.ServiceLocator helper class.

Let’s see a step by step introduction guided by the jtrTestBenchClient sample application.

The MultiplierSessionTest EJB-Runner

package jtr.test.jee.client;

import jtr.enterprise.ServiceLocator;

import jtr.runners.AbstractRunner;

import jtr.test.IOutcome;

import jtr.test.jee.MultiplierSessionRemote;

/**

* @author frusso

public class MultiplierSessionTest extends AbstractRunner {

/** Creates a new instance of MultiplierSessionTest */

public MultiplierSessionTest() {

}

public void test() throws Throwable {

MultiplierSessionRemote msr =

ServiceLocator.<MultiplierSessionRemote>getEJBObject(ejbName,

MultiplierSessionRemote.class,

getEnterprise());

System.out.println("Received message is "+msr.multiply(x,y));

}

public void receiveFailureNotification(Throwable throwable, String string) {

}

public void cleanupResources() {

}

public void enrichOutcome(IOutcome outcome) {

outcome.setUserObject("Running against "+getEnterprise().getUniqueName()+

"\nEJB JNDI name is: "+ejbName);

}

private String ejbName;

private double x,y;

}

As we can see form the source code above, the MultiplierSessionTest runner implements all of the methods discussed in the previous section. The only important thing to highlight is the way the runner can look-up every EJB it requires by means of the jtr.enterprise.ServiceLocator helper class.

The jtr.enterprise.ServiceLocator class

The ServiceLocator class lets you look-up EJBs that conforms to both the EJB 2.x and the EJB 3 specs. The method

public static <T> getEJBObject(String ejbName, Class remote, EnterpriseConfig enterprise)

requires as actual parameters:

•the JNDI name of the remote object that must be looked-up
•for EJB 3 EJBs the remote interface the retrieved object must adhere to, for EJB 2.x components the home class required for creating the EJB
•the enterprise configuration to be used

The type parameter T must be equal to the expected remote interface.

The EnterpriseConfig instance is the object-oriented representation of a jtr.xml file enterprise element, describing the properties required by the JTR-runtime to correctly perform the look-up operation.

Amongst all the methods inherited from the jtr.runners.AbstractRunner class, the getEnterprise() method allows you to obtain the configured enterprise configuration available to your runner.

Completing the example with the jtr.xml file

<?xml version = '1.0' encoding = 'UTF-8'?>

<!-- JTRunner is free software; you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2, or (at your option)

any later version.

-->

<test xmlns="http://jtrunner.sourceforge.net"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://jtrunner.sourceforge.net file:./config/jtr.xsd"

runs="10">

<factory key="IAssignmentPolicyFactory"

fqn="jtr.assigner.impl.DefaultAssignmentPolicyFactory" />

<factory key="ITestCompletionListener"

fqn="jtr.test.impl.DefaultTestCompletionListener" />

</factories>

<runner-fqn>jtr.test.jee.client.MultiplierSessionTest</runner-fqn>

<instance-count>2</instance-count>

<parameters-assignment-policy>

indexed

</parameters-assignment-policy>

</parameters>

<!--parameters>

</parameters-->

</runner>

</enterprise>

<property name="java.naming.factory.initial"

value="com.sun.enterprise.naming.SerialInitContextFactory"/>

<property name="java.naming.factory.state"

value="com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"/>

</enterprise>

</test>

With the above configuration file we have introduced a new runner category, the MultiplierSessionTest, stating that there will be 2 instances each of which will run for 4 times per epoch. The first instance is going to be parameterized with the first parameter-set, while the second parameter-set will be injected into the second instance.

We also have to note that the first instance is tied to the enterprise configuration called jboss, while the second one overrides this default category-level configuration, binding itself to the glassfish enterprise configuration.

Thus, at the bottom of the file, we find the two enterprise configurations required by the two instances: jboss and glassfish.

Next step: writing a JMS-enabled JTR-Runner