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 14:23:48 GMT
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