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] 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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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 [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
--
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
--
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