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 17:03:41 GMT
I'm thinking we're running into some serious classloading issues here - 
with OC4J.
 From 10.1.3 on up this part of the J2EE impl of Oracle has been 
massively changed.

What's strange though is that everything works as long as we don't do 
logging....?

Jan Vissers 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>> 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>] 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: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>
>>     >>> 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>]
>>     >>>> 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 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>
>>     >>>>
>>     >>>>
>>     >>>>
>>     >>>>
>>     >>> --
>>     >>> 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 <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