A simplier example for the NPE can be found here: http://www.mail-archive.com/[email protected]/msg11704.html
We do not use any procedures, only 2 simple queries with according result maps. The error occured within JRE 5. Regards, Kai Clinton Begin <mailto:[EMAIL PROTECTED]> wrote: > Make sure you're using JDK 5, not 6. We currently extend a couple of > JDBC 3 classes for SimpleDataSource. We've discussed using a dynamic > proxy to avoid this requirement, but that would slow a few things > down... still in discussion. :-) > > For now, JDK 5. I'll send you a link with a fixed build until I can > get the latest up on Apache. > > Clinton > > > On Tue, Jul 15, 2008 at 12:16 PM, <[EMAIL PROTECTED]> > wrote: > > > Here are the specifics. It's not very complex which is why it > surprised me so much. > > <procedure id="getCreditHoldFlag" resultClass="java.lang.Boolean"> > { call ${getCreditHoldFlag_sp} ( > @CustomerNumber = > #customerNo,jdbcType=VARCHAR,javaType=java.lang.String,mode=IN# > ) } > </procedure> > > > The parameter class is a String and I'm even specifying it in the SQL. > > One question about the patch, is it checked into the main trunk of > iBatis? I performed a sync but didn't seem to get anything and when I > try to build from the trunk I get two nasty errors: [INFO] > Compilation failure > > s:\iBatis\java\mapper\mapper2\src\com\ibatis\common\jdbc\SimpleDataSource.ja va:[ > 52,7] com.ibatis.common.jdbc.SimpleDataSource is not abstract and > does not overr > ide abstract method isWrapperFor(java.lang.Class) in java.sql.Wrapper > > s:\iBatis\java\mapper\mapper2\src\com\ibatis\sqlmap\engine\type\CallableStat emen > tResultSet.java:[29,7] > com.ibatis.sqlmap.engine.type.CallableStatementResultSet > is not abstract and does not override abstract method > updateNClob(java.lang.Stri > ng,java.io.Reader) in java.sql.ResultSet > > > > Thanks for the help Clinton.. > > > Chris > > > "Clinton Begin" <[EMAIL PROTECTED]> > 07/15/2008 11:09 AM > Please respond to > [email protected] > > [EMAIL PROTECTED] > cc > SubjectRe: NullPointerException after upgrade to 2.3.2 > > > > > > > > > I committed the patch, so you can build from SVN. > > HOWERVER.... I can't for the life of me reproduce the failure. > iBATIS usually detects the type of JavaBeans properties and for Maps > uses Object if it can't figure it out... so type should never really > be null. I can't write the failing unit test. > > Can you post (or email me directly if you don't want it published) > the offending statement, result map, parameter map, and stack trace? > > Thanks much, > Clinton > > On Tue, Jul 15, 2008 at 11:40 AM, <[EMAIL PROTECTED]> > wrote: > > Thank you Clinton.. > > Chris > > "Clinton Begin" <[EMAIL PROTECTED]> > 07/15/2008 10:38 AM > > > Please respond to > [email protected] > > [EMAIL PROTECTED] > cc > SubjectRe: NullPointerException after upgrade to 2.3.2 > > > > > > > > > > I'll add the patch now... and let you know when to grab from SVN. > > Clinton > > On Tue, Jul 15, 2008 at 11:29 AM, <[EMAIL PROTECTED]> > wrote: > > Is the fix committed so I can get it and build from SVN? > > Chris Mathrusse > [EMAIL PROTECTED] > Sybase, Inc > One Sybase Drive > Dublin, CA 94568 > (925) 236-5553 > "Clinton Begin" <[EMAIL PROTECTED]> > 07/15/2008 10:27 AM > > > Please respond to > [email protected] > > [EMAIL PROTECTED] > cc > SubjectRe: NullPointerException after upgrade to 2.3.2 > > > > > > > > > > > > Known bug, sorry about that. I hope to get to a fix soon... it's > easy, just time. > > Clinton > > On Tue, Jul 15, 2008 at 11:24 AM, <[EMAIL PROTECTED]> > wrote: > > I just upgraded to 2.3.2 due to the fact that Spring 2.5.5 seems to > need it. After I upgraded I am now getting a NullPointerException > after executing a procedure. This was working prior to the upgrade > and seems to be associated to the TypeHandlerFactory.setTypeHanlder > method at line 143. As I step through the code it appears that the > result is returned from the procedure. I can see the value returned > and my CustomTypeHandler is being invoked and is returning the > correct value. ('N' == Boolean.FALSE) > > It appears this error begins in the class > ComplexDataExchange.setData() method. On line 95 the following > statement is executed: > > if > (typeHandlerFactory.hasTypeHandler(parameterMap.getParameterClass())) > { > > However, my parameterMap has no parameterClass specified and when it > is retrieved a null value is returned. This causes the > NullPointerException to occur in the > TypeHandlerFactory.setTypeHanlder() method at line 143: > > if (handler == null && Enum.class.isAssignableFrom(type)) { > > The test is made to see if the handler is null but no test is > performed to see if the type is null and this results in the > NullPointerException. > > Is it now required to have a ParameterClass specified on every > statement? > > Chris
