Yeah, this is just a bad design. I would seriously recommend that you consider naming your methods explicitly. Overloading JavaBean properties isn't worth the problems you'll have, not only with iBATIS, but with many other bean frameworks.
Name the pure typed setID() normally. For type conversions, name the bean properties explicitly, like setIDString(); or more generic setIDText(). Overloading should be reserved for behaviour methods. State classes should rarely (i.e. never): 1) have overloaded properties, 2) implement interfaces that describe state, 3) use deep inheritance hierarchies. Keep your JavaBeans simple, clear, and explicit. Cheers, Clinton On Sat, 15 Jan 2005 00:40:17 -0500, Bing Zou <[EMAIL PROTECTED]> wrote: > I have been using iBATiS for about a week, it is great. Thanks a lot > for your excellent work. Now I have one question about the result > mapping: > > When the resultClass has overloaded methods, for example, setID(int > ID) and setID(String ID), it seems that iBATiS will use the first > setID() (say, setID(int ID)) method in the method list returned by > reflection API as the result mapping method. While if the result > column in the database is type varChar instead of int, I will get > result mapping Exception. > > I tried to switch the order of the two setID() methods in the class > and it worked. iBATiS picked up the first one (setID(String) now) in > the method list from reflection now. But I don't think this is a > correct way to solve this problem. I am wondering whether there is > some other way to do that? Actually, while using reflection to get the > setXXX method list, can we use Class.getMethod(String name, Class... > parameterTypes) instead of the general getMethods()? (Maybe this will > have a little bit impact on performance though.) > > Any though/help will be appreciated. > Have a nice weekend. > Xigua >
