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