Debashish,
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.
-Vadim
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
beginning)
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* <[EMAIL PROTECTED]
<mailto:[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]
<mailto:[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
>
