Support for XA data sources

[GoogleCodeExporter]

What steps will reproduce the problem?
1. define an XA data source (for H2 for example) using the class 
org.h2.jdbcx.JdbcDataSource

2. Wrap the data source defined in step #1 with 
net.sf.log4jdbc.sql.jdbcapi.DataSourceSpy

3. Reference the wrapped datasource via a JTA datasource such as 
com.atomikos.jdbc.AtomikosDataSourceBean 

What is the expected output? What do you see instead?
Expected to see jdbc spy logging output.  Instead I get an exception.

Caused by: java.lang.IllegalStateException: Cannot convert value of type 
[net.sf.log4jdbc.sql.jdbcapi.DataSourceSpy] to required type 
[javax.sql.XADataSource]

What version of the product are you using? On what operating system?

Using version 1.6

Please provide any additional information below.

We either need the DataSourceSpy class to implement javax.sql.XADataSource or 
we need a new class "XADataSourceSpy"

Thanks

Original issue reported on code.google.com by David.H....@gmail.com on 19 Mar 2014 at 3:33

[GoogleCodeExporter]

Indeed, a way to solve your issue could be to create a "XADataSourceSpy", and 
also a "XAConnectionSpy", but the problem is: should we provide support only 
for the method "PooledConnection#getConnection()" (that could be wrapped easily 
by a ConnectionSpy)? I don't really see the point for a XA resource. 

Providing a full support for XADataSources would be a completely new branch of 
log4jdbc, we would need to create "ConnectionEventListenerSpy", 
"StatementEventListenerSpy", "XAResourceSpy", etc. 

If you wanted to provide such a patch, I could consider it. 

Original comment by frederic...@gmail.com on 21 Mar 2014 at 12:34

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As a workaround, I've also found that my JTA transaction manager (Atomikos) has 
a datasource bean that can be used to wrap the XA datasources and thus provide 
the regular datasource interface that can be further wrapped by DataSourceSpy.  
e.g.:

    <!-- Atomikos's XA capable pooling data source. -->
    <bean id="myJTADataSource" class="com.atomikos.jdbc.AtomikosDataSourceBean">
        <property name="xaDataSource" ref="myh2XaDataSource" />
        <property name="uniqueResourceName" value="myDatabase" />
                ...
    </bean>

    <!-- Special logging wrapper for our data source that spys on JDBC calls -->
    <bean id="myJTADataSourceSpied" class="net.sf.log4jdbc.sql.jdbcapi.DataSourceSpy">
        <constructor-arg ref="myJTADataSource" />
    </bean>

I have to believe this approach is readily available for almost any JTA 
transaction manager that uses XA data sources.  IMO you can close this issue as 
won't fix because, as you said, its a lot of work to support XA natively and 
I'm not convinced now that there would be any benefit.

Original comment by David.H....@gmail.com on 24 Mar 2014 at 2:37

[GoogleCodeExporter]

Thanks for the update. Won't fix :)

Original comment by frederic...@gmail.com on 25 Mar 2014 at 1:47

• Changed state: WontFix