BTM
  1. BTM
  2. BTM-114

erroneous java.sql.Wrapper implementation

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.2
    • Fix Version/s: 3.0.0
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Calling unwrap(oracle.jdbc.OraclePreparedStatement.class) on a Bitronix prepared statement wrapper doesn't work while it should, the current code only allows ((OraclePreparedStatement)pstmt.unwrap(PreparedStatement.class)) calls.

      The same is true for all wrappers implementing java.sql.Wrapper.

      See: http://stackoverflow.com/questions/7984609/using-special-jdbc-driver-features-with-dynamic-proxy-connection-pools

        Activity

        Hide
        Ludovic Orban added a comment -

        Fixed and deployed a 2.1.3-SNAPSHOT version in the codehaus snapshot repository containing the fix.

        Show
        Ludovic Orban added a comment - Fixed and deployed a 2.1.3-SNAPSHOT version in the codehaus snapshot repository containing the fix.
        Hide
        Patrick Kelchner added a comment -

        Is the code in 2.1.3 a proper fix for this? The Javadoc for java.sql.Wrapper.isWrapperFor() reads (emphasis my own):

        Returns true if this either implements the interface argument or is directly or indirectly a wrapper for an object that does.

        That suggests that unwrap() should check if the delegate is itself a wrapper and call unwrap() on it if necessary, i.e.:

        public <T> T unwrap(Class<T> iface) throws SQLException {
            if (iface.isInstance(delegate))
                return (T) delegate;
        
            if (delegate instanceof Wrapper)
                return ((Wrapper)delegate).unwrap(iface);
        
            throw new SQLException(getClass().getName() + " is not a wrapper for " + iface.getName());
        }

        Same for isWrapperFor().

        Show
        Patrick Kelchner added a comment - Is the code in 2.1.3 a proper fix for this? The Javadoc for java.sql.Wrapper.isWrapperFor() reads (emphasis my own): Returns true if this either implements the interface argument or is directly or indirectly a wrapper for an object that does. That suggests that unwrap() should check if the delegate is itself a wrapper and call unwrap() on it if necessary, i.e.: public <T> T unwrap( Class <T> iface) throws SQLException { if (iface.isInstance(delegate)) return (T) delegate; if (delegate instanceof Wrapper) return ((Wrapper)delegate).unwrap(iface); throw new SQLException(getClass().getName() + " is not a wrapper for " + iface.getName()); } Same for isWrapperFor() .
        Hide
        Ludovic Orban added a comment -

        Indeed, this was overlooked.

        I'll fix this for the next release, thanks!

        Show
        Ludovic Orban added a comment - Indeed, this was overlooked. I'll fix this for the next release, thanks!
        Hide
        Ludovic Orban added a comment -

        I committed a slightly different (but apparently equivalent) patch to the master branch: http://git.codehaus.org/gitweb.cgi?p=btm-git.git;a=commit;h=25e15a125985ce25ff22213414d92e83521634fd. I'd be happy if you could review it and report back the outcome.

        Thanks!

        Show
        Ludovic Orban added a comment - I committed a slightly different (but apparently equivalent) patch to the master branch: http://git.codehaus.org/gitweb.cgi?p=btm-git.git;a=commit;h=25e15a125985ce25ff22213414d92e83521634fd . I'd be happy if you could review it and report back the outcome. Thanks!
        Hide
        Patrick Kelchner added a comment - - edited

        Sorry for the late feedback. I missed the notice that this issue had changed.

        I had a look at the changeset and noticed two points:

        First, the change to PoolingDataSource mangles the two cases that the xaDataSource may implement the requested interface directly or that it itself may be a wrapper.

        Second, is it possible that a wrapped delegate might only implement JDBC 3 interfaces and thus lack the methods from interface Wrapper? I think JLS-13.4.16 applies here which means a call to isWrapperFor() or unwrap() may fail with an AbstractMethodError.

        Show
        Patrick Kelchner added a comment - - edited Sorry for the late feedback. I missed the notice that this issue had changed. I had a look at the changeset and noticed two points: First, the change to PoolingDataSource mangles the two cases that the xaDataSource may implement the requested interface directly or that it itself may be a wrapper. Second, is it possible that a wrapped delegate might only implement JDBC 3 interfaces and thus lack the methods from interface Wrapper ? I think JLS-13.4.16 applies here which means a call to isWrapperFor() or unwrap() may fail with an AbstractMethodError .

          People

          • Assignee:
            Ludovic Orban
            Reporter:
            Ludovic Orban
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: