ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: OracleCallableStatement, log4j => PreparedStatementLogProxy (is this a bug?)
Date Mon, 05 Feb 2007 16:09:58 GMT
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> 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] Sent: Monday,
> >> February 05, 2007 4:18 PM
> >> To: 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]
> >>> Sent: Monday, February 05, 2007 4:08 PM
> >>> To: 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]
> >>>> Sent: Monday, February 05, 2007 3:44 PM
> >>>> To: 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
> >>>>
> >>>> E 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
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> 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
> >>
> >>
> >>
> >>
> >
>
> --
> 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