Java Reference
In-Depth Information
<!- - Other beans - ->
<bean id="testTopic"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="topic/testTopic" />
</bean>
<bean id="testQueue"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="queue/testQueue" />
</bean>
<bean id="resourceRefOnQueue"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="queue/resourceRefOnQueue" />
<property name="resourceRef" value="true" />
</bean>
<bean id="sampleQueue"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/topic/resourceRefOnQueue"
</bean>
/>
</beans>
As shown in Listing 4-7, you can use the
JndiObjectFactoryBean
to look up JMS
objects from the JNDI. In the case of remote JMS objects, you will just need to add the
jndiEnvironment
property in the same way as the EJB session bean in Listing 4-3.
As already discussed, object retrieval from the JNDI can be detrimental to perform-
ance. In highly transactional applications, JNDI objects will be used regularly. So, it is
imperative that the clients cache and use these objects. This is exactly what the
JndiObjectFactoryBean
does by default. It looks up the JNDI tree when the Spring web
application context is being initialized and loads the JNDI bound objects. Hence, it is
necessary that the EJBs are loaded and registered in the JNDI before the Spring web
application starts initialization.
The object caching feature of the service locator is not very important for applica-
tions that sparingly use JNDI objects. This will also cause problems if you update your
application with hot deployment support from the application servers. Hot deployment
allows an entire Java EE application to be reloaded without bringing down the server.
This will also refresh the JNDI with new objects. As a result, the service locator cache, if
used, will have object references that no longer exist. Hence, any further access to these
objects will result in runtime exceptions being raised.
It is possible to look up and load JNDI objects lazily in the Spring IOC container. If
JNDI object retrieval at startup and subsequent caching had to be turned off, you must
