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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>] Sent: Monday,
> >> February 05, 2007 4:18 PM
> >> To: 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:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>]
> >>> Sent: Monday, February 05, 2007 4:08 PM
> >>> To: 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:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>]
> >>>> Sent: Monday, February 05, 2007 3:44 PM
> >>>> To: 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
> >>>>
> >>>> E [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >>>> M +31 6 51 169 556
> >>>> B 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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >>> 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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >> 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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> 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 [EMAIL PROTECTED]
M +31 6 51 169 556
B http://www.cumquat.nl/technology_atom10.xml
