Let me see if I can explain this correctly...
Basically, when a RequestFactory interface is validated it fails if
any of the "property" methods of the mapped entity class are
overloaded. So basically, if I understand this correctly, for every
method defined on the EntityProxy interface, if more than one method
of the same name is found via reflection on the EntityProxy's
@ProxyFor class, then validation fails. This validation check does not
take into account the parameters specified by the overloaded methods,
and so, for methods that only change the return type (covariance),
this check still fails.
So, an entity type hierarchy like so is *not* supported...
interface IEntity {
Object getId();
}
@MappedSuperclass
abstract class BaseEntity implements IEntity {
Integer version;
Integer getVersion() { return version; }
}
@Entity
class RealEntity extends BaseEntity {
@Id
Long id;
Long getId() { return id; }
}
... Because RealEntity.class has 2 "getId" methods and is thus
considered "overloaded" even though the methods only differ by return
type.
If this is totally intended or required, can someone explain it to me?
Because, to me, it seems viable to support this.
If it is viable, I guess the only way to do this right would be to
introspect the list of same-name methods and make sure all the
parameter lists match. And only then allow it to be "validated". That
sound about right? If so, I'll see what I can do to put something
together.
Thanks,
-matt
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
