JTR 3.1: EJB 3 ready
JTR 3.1: EJB 3 ready
This new JTR minor release features a set of improvements that extend the usability and improve the overall experience of the developer. It introduces support to EJB 3 session beans too.
Follows a brief report of the most relevant updates:
0. Support to EJB 3 session beans lookup and instantiation
1. More IRunner concrete implementation are allowed to use at runtime the same JMS-configuration even if one of the configured JMS-connections is declared as not shareable. This can be accomplished declaring that the clientId for that connection instances has to be initialized with the IRunner unique-id automatically generated by the JTR runtime. Follows an example for your convenience:
<jms uniqueName="jboss-jms">
<destinations>
<queues>
<queue property="queue" jndi="queue/myTestQueue" />
</queues>
</destinations>
<conn-factories>
<conn-factory property="queueConnFactory"
jndi="QueueConnectionFactory">
<connections>
<connection shared="false" clientId="${runner.id}"
property="queueConn" type="queue">
<sessions>
<session property="queueSess" ackMode="1"
type="queue" transacted="true" />
</sessions>
</connection>
</connections>
</conn-factory>
</conn-factories>
</jms>
As you can see, this JMS-configuration defines an unshared queue-connection element that will be injected into an IRunner property named queue. Every JMS client-connection has to be uniquely identified by a client-id. With JTR 3.0 and prior versions if you wanted to use the very same JMS-configuration with different Runner configurations, you were required to define its connection(s) as shared. That was because the JTR runtime did not automatically handle the generation and assignment of client-ids to JMS-connections.
Now you can reuse a JMS-configuration even if it is not declared as shared: the only thing you have to do is declaring the clientId connection attribute as ${runner.id}. This is a placeholder that is equal to the IRunner concrete implementation runtime unique-identifier.
2. Your IRunner concrete implementations are no longer required to provide public setter methods for those properties that should be injected according to the configuration provided in the jtr.xml file: only private properties can suffice.
3. Another version of the ServiceLocator.getEJBObject(...) method has been added. This new version changes the last accepted parameter from Hashtable to EnterpriseConfig, and should be used in place of the former one for newly developed runners.
Sunday, 24 September 2006