ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Grinshpun <va...@ll.mit.edu>
Subject Re: locating errors in SqlMap
Date Wed, 19 Jul 2006 14:32:38 GMT
I can see where you are coming from, but there are some situations where 
iBATIS is not as well-behaved.
Situations where iBATIS error messages are not very helpful include 
basic things like a typo in the XML(a missing quote, or close tag), in 
which case the parser goes completely berserk in its interpretation of 
the xml file. Also, if the same result map is re-used in multiple 
places, or you have identical column names in different tables (or 
property names in different beans), the error messages shown are not 
specific enough to identify the culprit easily.  Having a line number, 
or the name of the select statement, would be very helpful.

I wish I could provide examples, but the system I work on is not 
connected to the net, and getting data off is a rather painful process.

PS for the record--I do have logging turned on, it is indeed a 
lifesaver; and I've been using iBATIS for a few months now, so I've 
learned to recognize many of the things that were confusing at the 

Debasish Dutta Roy wrote:
> I would opt to disagree.
> Following the suggestions would surely help. You can also put logs for 
> iBATIS. There are many email threads about that.
> I have made many minor to major mistakes in the sql-map files and have 
> been pointed quite well by iBATIS.
> E.g. I do get logs like this
> com.ibatis.common.jdbc.exception.NestedSQLException:  
> --- The error occurred in xml/Request.xml. 
> --- The error occurred while applying a parameter map. 
> --- Check the updateRequestNumber-InlineParameterMap. 
> --- Check the parameter mapping for the 'number' property. 
> --- Cause: java.sql.SQLException: Invalid column type
> Caused by: java.sql.SQLException: Invalid column type
> OR,
> Caused by: com.ibatis.common.xml.NodeletException : Error parsing 
> XML.  Cause: com.ibatis.common.exception.NestedRuntimeException: Error 
> parsing XPath '/sqlMapConfig/sqlMap'.  Cause: 
> com.ibatis.common.xml.NodeletException: Error parsing XML.  Cause: 
> com.ibatis.common.exception.NestedRuntimeException : Error parsing 
> XPath '/sqlMap/select'.  Cause: 
> com.ibatis.sqlmap.client.SqlMapException: There is no result map named 
> Profile.get-PPI-select-values in this SqlMap.
> Caused by:
> And I exactly know where to go. Also, get the source code in your path 
> and you can debug the source code also. That will surely help.
> Best Regards
> Debasish
> On 7/18/06, *Ted Schrader* <tschrader@gmail.com 
> <mailto:tschrader@gmail.com>> wrote:
>     Hi Vadim,
>     I feel your pain in quietly cursing iBATIS' seemingly mystical error
>     messages when I was first starting out.
>     I'm not aware of any way to make iBATIS' error mechanism more verbose.
>     In practice, I do the following, along with your suggestion of
>     commenting out parts of the map:
>     1.  Keep the SQL Map XML files concise.
>     2.  Separate SQL Map XML files into logical units.
>     I reckon a good idea would be to start a catalog of various error
>     messages on the wiki, or maybe even a full-blown debugging strategy
>     section (I didn't see one after a quick perusal of the wiki today).
>     Taking your example:
>     Error:
>     "no readable property named FOO"
>     Problem:
>     iBATIS cannot find the FOO property on the class specified in the
>     result map.
>     Resolution (the usual suspects):
>     Does the class have a FOO property?
>     Does the class adhere to JavaBeans specifications?
>     Is the result map element free of typos?
>     I suspect this could turn out to be an extremely helpful resource if
>     maintained, but I personally lack the time to get this sort of thing
>     started.  Any takers?
>     Ted
>     On 18/07/06, Vadim Grinshpun <vadim@ll.mit.edu
>     <mailto:vadim@ll.mit.edu>> wrote:
>     > Hi all,
>     >
>     > in a situation where iBATIS's parser throws an exception, is
>     there a way
>     > to tell which part of the sql map being parsed is actually the
>     culprit?
>     > The error shown in the exception is too vague, and doesn't point
>     to a
>     > particular file/line/xml element/whatnot. Specifically, I have a
>     case of
>     > a "no readable property named FOO", but the FOO in question is being
>     > used in a number of places, a number of which have just been
>     modified. I
>     > could try to track it down by commenting out different parts of
>     the map
>     > to see which part(s) make the error go appear/go away, but I was
>     hoping
>     > there might be a more intelligent way to approach this.
>     >
>     > If there isn't a better way to do this currently, is it feasible
>     to add
>     > better error reporting facilities into the parser, and are there any
>     > plans to do so?
>     >
>     > Thanks for any advice.
>     > -Vadim
>     >

View raw message