Atomikos Forum

Hi,

Can I ask, please, why there is no public setter for a datasource, like setXaDataSource(XADataSource xaDS) on AtomikosDataSourceBean?
Looking at the code of AtomikosDataSourceBean, it seems to me that instead of passing all needed details for constructing the datasource to AtomikosDataSourceBean, we could instead call setUniqueResourceName(String) and a new setXaDataSource(XADataSource xaDS). setXaDataSource(...) should in this case do the extra stuff that is done in doInit() AFTER constructing the datasource.

WHY AM I ASKING FOR a public setXaDataSource(XADataSource xaDS) setter?
Simple: because I want to pass an already constructed XaDataSource (constructed already by Tomcat as a Resource in server.xml) and because I DO NOT want to polute the commons/lib and server/lib with the atomikos jars as described in http://www.atomikos.com/Documentation/Tomcat55Integration33, especially that I'm keeping the JTA Atomikos UserTransaction setup inside the spring file inside my web application. So I would like to keep all atomikos jars in my web app, but still have the DataSource defined as a resource in server.xml of Tomcat and I cannot do this because AtomikosDataSourceBean does not allow passing to it of an already constructed datasource.

Is there any chanse that this will change in the future (example add a public method setXaDataSource(XADataSource xaDS)) to AtomikosDataSourceBean?
If not, why? If yes, any time scale for it?

Thank you very much,
Valentin

Hi,

Your request makes sense. The reason why it is not there: we never add functionality (beyond the basic one) before somebody actually needs it. So here we are;-)

Concerning the possibility of adding this: we will schedule this for a future release (3.5 or later) or - if you want to sponsor with dev support to get it sooner - we might also consider this for our 3.4 release later this month.

Let me know.

Best
Guy

Thanks for your fast answer. I would love to contribute to this, but we are passing now through a period of high presure (tight deadlines) and I have not got any time for this from my manager. What I will do for now is that I will put in JNDI all needed simple properties (like username, password, url and so on) which are depending on environment (like dev, test, production, etc), because this is our policy, and I will construct the AtomikosDataSourceBean in Spring using these settings from jndi. But like I said, this is not as beautiful as having a normal datasource (like oracle.jdbc.xa.client.OracleXADataSource and not AtomikosDataSourceBean) created in JNDI.

Another small comment on the reason why I do not like to polute the shared/lib or common/lib folder of Tomcat with Atomikos jars and other jars (and instead keep them inside the war) is that would create classpath problems (solvable but with ugly solutions) when we deploy multiple applications into the same container, applications developed and tested with different versions of various libraries (including Atomikos). And sometimes the solutions for these classpath problems are really dificult...