There is a strange consequence of using generics in this way - Java
reflection will report that there are two getKey methods and two setKey
methods. The difference is that one set will use the Key type, and another
set will use the actual final implementation type.
iBATIS 2.x is not setup to deal with this wierd side effect of using
generics this way and I have seen unpredictable results - sometimes it
works, sometimes it doesn't. Sometimes it works in debug mode and not in
regular run mode. It seems to depend on the order in which the reflection
calls return class methods.
My best advice for now is - don't do this. iBATIS, obviously, does not
support this usage reliably.
I can forward a short test case to you if you are interested in seeing the
issue.
Jeff Butler
On Thu, Aug 7, 2008 at 1:37 PM, Martín Capote
<[EMAIL PROTECTED]>wrote:
> Hi, sorry for my english, I speak spanish.
> I have a question about generics.
> I have an application running with ibatis 2.3.0, and I tried to 'generify'
> some parts.
>
> I introduce the "Keyable" interface:
>
> public interface Keyable<K extends Key> {
>
> public K getKey();
>
> public void setKey(K key);
>
> }
>
>
> The Key is a simple abstract class:
>
>
> public abstract class Key {
> public Key() {
> super();
> }
> }
>
>
> Then, I declare my business object in this way :
>
>
> public class Person implements Keyable<PersonKey> {
> ...
> }
>
> public class PersonKey extends Key {
> private String code;
> ....
> }
>
>
> And declare the resultMap in this way:
> ...
> <resultMap id="PersonResult" class="Person">
> <result property="key.code" column="CODE" />
> ...
>
> But i get this error:
>
> Caused by: com.ibatis.common.beans.ProbeException: There is no WRITEABLE
> property named 'code' in class 'com.pack.Key'
> at
> com.ibatis.common.beans.ClassInfo.getSetterType(ClassInfo.java:273)
> at
>
> com.ibatis.common.beans.GenericProbe.getClassPropertyTypeForSetter(GenericPr
> obe.java:248)
> ...
>
>
>
> My first (and naive, I think) solution is:
>
> - add the getPersonKey() method to the Person class (which returns
> explicitly the PersonKey)
> - modify the resultMap, so that the property look like this:
> property="personKey.code"
>
> But is an ugly solution, and a lot of work.
> And I want to retain the generics.
> There is some better solution to this problem?
> Thanks
> Martín
>
>
