ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Vissers <Jan.Viss...@cumquat.nl>
Subject Re: OracleCallableStatement, log4j => PreparedStatementLogProxy (is this a bug?)
Date Mon, 05 Feb 2007 18:30:01 GMT
Hi,

Managed to get things working with both commons-logging/log4j and ojdbc 
stuff.
As you explained below - whenever I set java.sql.Connection to a value 
of 'DEBUG' things stop working, when I cast to OracleCallableStatement.

I'm guessing this is what you meant by the usage of "getPs()"
This would mean that we code things like:

    OracleCallableStatement cstmt = null;
    if( c instanceof java.sql.Connection ) {
        cstmt = (OracleCallableStatement)c.prepareCall(SOME_CALL);
    } else {
        cstmt = 
(OracleCallableStatement)(((PreparedStatementLogProxy)c.prepareCall(SOME_CALL)).getPs());
    }

Correct?
-J.

Jeff Butler wrote:
> iBATIS does different things depending on the logging level.  If 
> logging is enabled on java.sql.Connection, then you'll get the proxied 
> classes  (which are proxied yet again by Oracle).  If not, you'll get 
> the actual classes (again, proxied by Oracle).  To be completely safe, 
> you need to allow for both possibilities (with an instanceof check - 
> ugh).
>  
> Also, this is not related to commons-logging vs. log4j.  The 
> difference must be that you had logging enabled in your log4j config 
> and not enabled in your commons-logging config.  This is very easy to 
> do - because the commons-logging config is often very high in the 
> class loader hierarchy and hard to override.
>  
> So, because of this pecularity in the way that iBATIS does logging, 
> there will necessarily be some intrusions into your code - unless you 
> decide to stop logging altogether.
>  
> With that in mind, I still think the getPs() method is least intrusive 
> into iBATIS with a minimal additional intrusion into your code.
>  
> Does this make sense?
>  
> Honestly, I'm not convinced that this is the best way to do logging 
> going forward into iBATIS 3.0, but that's another topic completely.
>  
> Jeff Butler
>  
>  
>  
>  
>
>
>  
> On 2/5/07, *Jan Vissers* <Jan.Vissers@cumquat.nl 
> <mailto:Jan.Vissers@cumquat.nl>> wrote:
>
>     Hi Jeff,
>
>     Thanks for this suggestion.
>     A couple of things to note here;
>
>     Not sure whether this is (really) an iBatis issue - it might be that
>     we're running into OC4J (Oracle's J2EE impl) specific behavior.
>
>     OC4J has managed and unmanaged datasources. We're currently using
>     managed datasources, which means OC4J will
>     return proxied SQL resources we can use. I'm not sure whether this
>     might
>     be resulting in issues when using iBatis.
>
>     Furthermore, I find it peculiar that when I change the logging
>     settings,
>     for instance have 'ERROR' on iBatis specified
>     instead of 'DEBUG' the classcast exception error I get is different:
>
>     + java.lang.ClassCastException : $Proxy14 .... ( 'DEBUG')
>     + java.lang.ClassCastException:
>     oracle_jdbc_driver_T4CCallableStatement_Proxy : ('ERROR')
>
>     I would prefer I we just could get a 'CallableStatement' handle
>     without
>     doing something linke 'getPs()' - this
>     would be more intrusive for our applications.
>
>     Your thoughts please...
>     -J.
>
>
>     Jeff Butler wrote:
>     > How about if we add a getPs() method to the
>     PreparedStatementLogProxy
>     > that returned the wrapped PreparedStatement.  Then you could
>     cast the
>     > wrapped prepared statement to the oracle callable statement.  This
>     > would be quick and easy, and would (I think) solve the
>     issue.  This is
>     > also similar to what Larry added recently on the ResultSetLogProxy.
>     >
>     > Jeff Butler
>     >
>     >
>     >
>     >
>     > On 2/5/07, *Jan Vissers* <Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>
>     > <mailto:Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>>>
>     wrote:
>     >
>     >     This MUST be a bug right?
>     >
>     >     49        if ("prepareStatement".equals( method.getName())) {
>     >     50          PreparedStatement stmt = (PreparedStatement)
>     >     method.invoke(connection, params);
>     >     51          stmt = PreparedStatementLogProxy.newInstance(stmt,
>     >     (String)
>     >     params[0]);
>     >     52          return stmt;
>     >     53        } else if ("prepareCall".equals( method.getName())) {
>     >     54          PreparedStatement stmt = (PreparedStatement)
>     >     method.invoke(connection, params);
>     >     55          stmt = PreparedStatementLogProxy.newInstance(stmt,
>     >     (String)
>     >     params[0]);
>     >     56          return stmt;
>     >     57        } else if ("createStatement".equals(
>     method.getName())) {
>     >     58          Statement stmt = (Statement)
>     method.invoke(connection,
>     >     params);
>     >     59          stmt = StatementLogProxy.newInstance(stmt);
>     >     60          return stmt;
>     >     61        } else {
>     >     62          return method.invoke(connection, params);
>     >     63        }
>     >
>     >     Just I hunch but shouldn't lines 53 until 56 read:
>     >
>     >     53        } else if ("prepareCall".equals( method.getName())) {
>     >     54          CallableStatement stmt = (CallableStatement)
>     >     method.invoke(connection, params);
>     >     55          stmt = CallableStatementLogProxy.newInstance(stmt,
>     >     (String)
>     >     params[0]);
>     >     56          return stmt;
>     >
>     >     This means a class CallableStatementLogProxy should be
>     introduced?
>     >
>     >     If not a bug, then for clarity...
>     >
>     >     -J.
>     >
>     >
>     >
>     >     Jan Vissers wrote:
>     >     > Well okay then,
>     >     >
>     >     > It's just I need to cast to an Oracle specific JDBC
>     >     CallableStatement,
>     >     > because I want to retrieve Oracle's
>     >     > XMLType from the underlying stored function/procedure.
>     >     > Like so:
>     >     >
>     >     >        ocstmt =
>     (OracleCallableStatement)c.prepareCall(VALUECALL);
>     >     >         ocstmt.registerOutParameter(1,
>     >     oracle.jdbc.OracleTypes.OPAQUE,
>     >     > "SYS.XMLTYPE");
>     >     >        ocstmt.setString(2, name);
>     >     >        ocstmt.execute();
>     >     >        OPAQUE opaque = ocstmt.getOPAQUE(1);
>     >     >        XMLType xml = XMLType.createXML(opaque);
>     >     >
>     >     > The call to getOPAQUE() allows me to get to the XMLType
>     underneath.
>     >     >
>     >     > -J.
>     >     >
>     >     >
>     >     > Hofri Yehuda wrote:
>     >     >> :-))))
>     >     >> I meant don't use casting to oracle types... Sorry for
>     the bad
>     >     >> language...
>     >     >>
>     >     >> -----Original Message-----
>     >     >> From: Jan Vissers [mailto: Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>
>     >     <mailto: Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>>] Sent: Monday,
>     >     >> February 05, 2007 4:18 PM
>     >     >> To: user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>
>     >     <mailto: user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>>
>     >     >> Subject: Re: OracleCallableStatement, log4j =>
>     >     PreparedStatementLogProxy
>     >     >> (is this a bug?)
>     >     >>
>     >     >> Hi Hofri -
>     >     >> not sure why you are saying: "iBatis, don't use it!!!"
>     (in Dutch).
>     >     >>
>     >     >> However - just to make sure I'm not misunderstood - I
>     like the
>     >     iBatis
>     >     >> framework and we tend to use it regularly. It's just now and
>     >     then there
>     >     >> is something that is not really clear (to me). Most of
>     the time
>     >     it has
>     >     >> to do with me not using the framework properly or another
>     thing
>     >     that
>     >     >> gets in the way.
>     >     >> Anyway, hope somebody else has a more valuable comment
>     than you...
>     >     >>
>     >     >> Thanks,
>     >     >> -J.
>     >     >>
>     >     >> Hofri Yehuda wrote:
>     >     >>
>     >     >>> iBatis, gebruik het niet!!!
>     >     >>> -----Original Message-----
>     >     >>> From: Jan Vissers [mailto: Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>
>     >     <mailto:Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>>]
>     >     >>> Sent: Monday, February 05, 2007 4:08 PM
>     >     >>> To: user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>
>     >     <mailto:user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>>
>     >     >>> Subject: Re: OracleCallableStatement, log4j =>
>     >     >>> PreparedStatementLogProxy (is this a bug?)
>     >     >>>
>     >     >>> Thank you, but this is not going to help me.
>     >     >>>
>     >     >>> Somewhere along the way the behavior of iBatis with/without
>     >     logging
>     >     >>> has been changed - and I want to now where.
>     >     >>> I suspect that the PreparedStatementLogProxy is wrong, as it
>     >     should
>     >     >>> still allow me to get to the OracleCallableStatement.
>     >     >>>
>     >     >>> Also, I'm not sure whether the following piece of ibatis
>     Code in
>     >     >>> ConnectionLogProxy.java is causing me problems.
>     >     >>>
>     >     >>>       } else if ("prepareCall".equals(method.getName())) {
>     >     >>>         if (log.isDebugEnabled()) {
>     >     >>>           log.debug("{conn-" + id + "} Preparing Call: " +
>     >     >>> removeBreakingWhitespace((String) params[0]));
>     >     >>>         }
>     >     >>>         PreparedStatement stmt = (PreparedStatement)
>     >     >>> method.invoke (connection, params);
>     >     >>>         stmt = PreparedStatementLogProxy.newInstance(stmt,
>     >     (String)
>     >     >>> params[0]);
>     >     >>>         return stmt;
>     >     >>>
>     >     >>> Can somebody explain?
>     >     >>> Thanks,
>     >     >>> -J.
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>> Hofri Yehuda wrote:
>     >     >>>
>     >     >>>> try:
>     >     >>>>            WrappedConnection wrappedConn =
>     >     (WrappedConnection) conn;
>     >     >>>>             Connection underlyingConn =
>     >     >>>> wrappedConn.getUnderlyingConnection();
>     >     >>>>             OracleConnection oracleConn =
>     (OracleConnection)
>     >     >>>> underlyingConn;
>     >     >>>>
>     >     >>>>
>     >     >>>> -----Original Message-----
>     >     >>>> From: Jan Vissers [mailto:Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>
>     >     <mailto: Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>>]
>     >     >>>> Sent: Monday, February 05, 2007 3:44 PM
>     >     >>>> To: user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>
>     >     <mailto:user-java@ibatis.apache.org
>     <mailto:user-java@ibatis.apache.org>>
>     >     >>>> Subject: OracleCallableStatement, log4j =>
>     >     >>>> PreparedStatementLogProxy (is this a bug?)
>     >     >>>>
>     >     >>>> Hi,
>     >     >>>>
>     >     >>>> Environment:
>     >     >>>>   + OC4J 10.1.3.2.0
>     >     >>>>   + OJDBC 10g
>     >     >>>>   + ibatis (2.2.0/2.1.0)
>     >     >>>>   + with and without logging
>     >     >>>>
>     >     >>>> Consider the following Java/DAO code:
>     >     >>>>
>     >     >>>> public class JdbcCallExecutorDAO extends JdbcDaoTemplate
>     >     implements
>     >     >>>> ICallExecutor {
>     >     >>>>    ....
>     >     >>>>
>     >     >>>>         OracleCallableStatement ocstmt = null;
>     >     >>>>         String returnValue = null;
>     >     >>>>         try {
>     >     >>>>             Connection c = getConnection();
>     >     >>>>             System.err.println("Connection retrieved from
>     >     iBatis DAO=
>     >     >>>>
>     >     >>> "
>     >     >>>> + c);
>     >     >>>>             ocstmt = (OracleCallableStatement)
>     >     >>>> c.prepareCall(VALUECALL); /= ERRORLINE
>     >     >>>>             System.err.println("CallableStatement
>     retrieved from
>     >     >>>> iBatis DAO= "+ ocstmt);
>     >     >>>>             ocstmt.registerOutParameter(1,
>     >     java.sql.Types.VARCHAR);
>     >     >>>>             ocstmt.setString(2, name);
>     >     >>>>             ocstmt.execute ();
>     >     >>>>    ....
>     >     >>>>
>     >     >>>> Without log4j/commons-logging enabled this code work
>     without a
>     >     >>>> problem, however when I enable log4j/commons-logging a
>     >     >>>> ClassCastException occurs at //= ERRORLINE with a
>     message like:
>     >     >>>>
>     >     >>>>         java.lang.ClassCastException : $Proxy14
>     >     >>>>            .....
>     >     >>>>
>     >     >>>> When I remove the (OracleCallableStatement) and use plain
>     >     >>>> CallableStatement assignment, it works again. I've had
>     a look at
>     >     >>>> "PreparedStatementLogProxy" and particularly this part:
>     >     >>>>
>     >     >>>> ...
>     >     >>>>
>     >     >>>>     public static PreparedStatement
>     >     newInstance(PreparedStatement
>     >     >>>> stmt, String sql) {
>     >     >>>>        InvocationHandler handler = new
>     >     PreparedStatementLogProxy(stmt,
>     >     >>>>
>     >     >>>
>     >     >>>> sql);
>     >     >>>>        ClassLoader cl =
>     PreparedStatement.class.getClassLoader();
>     >     >>>>        return (PreparedStatement)
>     Proxy.newProxyInstance(cl, new
>     >     >>>> Class[]{PreparedStatement.class, CallableStatement.class
},
>     >     handler);
>     >     >>>>     }
>     >     >>>>
>     >     >>>> ...
>     >     >>>>
>     >     >>>> I'm wondering whether this is correct. Basically I
>     expect my
>     >     behavior
>     >     >>>>
>     >     >>
>     >     >>
>     >     >>>> to be the same with or without logging.
>     >     >>>>
>     >     >>>> Thank you,
>     >     >>>> -J.
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>> --
>     >     >>>> Cumquat Information Technology
>     >     >>>> De Dreef 19
>     >     >>>> 3706 BR Zeist
>     >     >>>> T +31 (0)30 - 6940490
>     >     >>>> F +31 (0)30 - 6940499
>     >     >>>> W http://www.cumquat.nl <http://www.cumquat.nl>
>     >     >>>>
>     >     >>>> E Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl> <mailto:Jan.Vissers@cumquat.nl
>     <mailto:Jan.Vissers@cumquat.nl>>
>     >     >>>> M +31 6 51 169 556
>     >     >>>> B http://www.cumquat.nl/technology_atom10.xml
>     >     <http://www.cumquat.nl/technology_atom10.xml
>     <http://www.cumquat.nl/technology_atom10.xml>>
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>> --
>     >     >>> Cumquat Information Technology
>     >     >>> De Dreef 19
>     >     >>> 3706 BR Zeist
>     >     >>> T +31 (0)30 - 6940490
>     >     >>> F +31 (0)30 - 6940499
>     >     >>> W http://www.cumquat.nl
>     >     >>>
>     >     >>> E Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>
>     <mailto:Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>>
>     >     >>> M +31 6 51 169 556
>     >     >>> B http://www.cumquat.nl/technology_atom10.xml
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>
>     >     >> --
>     >     >> Cumquat Information Technology
>     >     >> De Dreef 19
>     >     >> 3706 BR Zeist
>     >     >> T +31 (0)30 - 6940490
>     >     >> F +31 (0)30 - 6940499
>     >     >> W http://www.cumquat.nl
>     >     >>
>     >     >> E Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>
>     <mailto: Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>>
>     >     >> M +31 6 51 169 556
>     >     >> B http://www.cumquat.nl/technology_atom10.xml
>     >     >>
>     >     >>
>     >     >>
>     >     >>
>     >     >
>     >
>     >     --
>     >     Cumquat Information Technology
>     >     De Dreef 19
>     >     3706 BR Zeist
>     >     T +31 (0)30 - 6940490
>     >     F +31 (0)30 - 6940499
>     >     W http://www.cumquat.nl
>     >
>     >     E Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>
>     <mailto:Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>>
>     >     M +31 6 51 169 556
>     >     B http://www.cumquat.nl/technology_atom10.xml
>     >
>     >
>     >
>
>     --
>     Cumquat Information Technology
>     De Dreef 19
>     3706 BR Zeist
>     T +31 (0)30 - 6940490
>     F +31 (0)30 - 6940499
>     W http://www.cumquat.nl
>
>     E Jan.Vissers@cumquat.nl <mailto:Jan.Vissers@cumquat.nl>
>     M +31 6 51 169 556
>     B http://www.cumquat.nl/technology_atom10.xml
>
>
>

-- 
Cumquat Information Technology
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)30 - 6940499
W http://www.cumquat.nl

E Jan.Vissers@cumquat.nl
M +31 6 51 169 556
B http://www.cumquat.nl/technology_atom10.xml



Mime
View raw message