Datasource config for shared EAR contexts (Websphere)

I have read the following very helpful posts about setting up a parent EAR context that can be shared between WARs. My question is about how best to set up datasources under such a config (for Websphere).

http://springtips.blogspot.com/2007/...n-context.html
http://blog.springsource.com/2007/06...g-application/

If you have DAO beans defined in a shared EAR context, which want to @Autowire a Datasource... Or you have @Service beans which use @Transactional.... Then, I presume that you need to have your Datasource and TransactionManager beans also defined in the EAR context.

My problem is that we are currently using Datasource resource references defined in the web.xml for each WAR. How to make these visible to the EAR context? We currently use a shared Datasource definition defined in the Websphere console. The WAR resource references refer to this shared Datasource.

One approach I am considering is to make the DAO and Service beans in the EAR prototypes. And leaving the Datasource and TransactionManager beans defined in each WAR. The idea being that whenever an individual WAR uses such a bean, the individual WAR Datasource and/or TransactionManager will be used. I don't know if there are any pitfalls to this approach, other than marginal extra overhead associated with prototypes. I don't really want to do it this way, because it just seems non-standard and stupid.

Another approach would be to abandon WAR resource references, and define a Datasource bean in the EAR context using the JNDI reference for the console Datasource directly. One issue with this is that it makes Websphere cranky. It emits a warning if you do not use a resource reference. Another issue is that we have found it necessary to tweak the default settings on the resource reference (Unshareable). I don't know how we could preserve this setting without a resource reference.

Finally, Websphere provides a way to define Datasources at the EAR level, using a thing called "The WebSphere Enhanced EAR editor". But this looks clunky. It appears if you do it this way, you are embedding a JDBC provider, and Datasource, including drivers, usernames, and passwords within your application EAR binary.

So, this is almost more of an appserver question. Is there a way to define a resource reference to a console Datasource at the EAR level in Websphere? I am also asking what the standard approach for datasource config in a shared EAR context would be for other application servers. ie TCServer/Jboss.

Thanks in advance for any advice!

- Dom

I have found that the JNDI lookup on a jee:jndi-lookup does not occur on container load, but on each execution, and this saves the day. So, the datasource bean will live in the EAR context, but it serves as sort of a proxy to the WAR resource reference. The transaction manager lives in the EAR context as well. So, no problem!

So, my EAR context looks like this..

Code:

---

        <aop:aspectj-autoproxy/>
       
        <context:component-scan base-package="com.ao" />
        <context:component-scan base-package="net.cts" />
       
        <jee:jndi-lookup
                id="DB2"
                jndi-name="DB2" cache="true"
                resource-ref="true"
                lookup-on-startup="false"
                proxy-interface="javax.sql.DataSource" 
        />
       
        <tx:annotation-driven />
       
        <bean id="transactionManager"
              class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
                <property name="dataSource" ref="DB2"/>
        </bean>

---

And each WAR context looks like this

Code:

---

<!-- nothing here! -->

---

Looking at this more carefully...

The jee:jndi-lookup allows you to control whether or not the JNDI lookup occurs on startup or not with the lookup-on-startup property. Also, you can control caching with the cache property. I suppose that if you cache at the EAR level, then it becomes possible for the resource reference of one WAR to be used by another WAR. As long as the resource references are set up identically across WARs, I don't know if there would be any ill effects.

Also, I have found that I had to put <context:component-scan /> in each WAR context. It could not be completely empty or Autowiring would not work in the WAR container. This was causing AutowiringRequestProcessor not to work. It may be necessary to also include <aop:aspectj-autoproxy/> and <tx:annotation-driven />, if you have WAR specific beans.