I've determined that his is because the 'getId' method defined in my
interface has a return type of 'Object', which differs from the actual
return type of my concrete classes 'Long'. A structure like this
causes Class.getMethods() to return 2 methods, one for the base-
interface, and one for the concrete implementation. When this happens,
RequestFactoryModel.validateExistsAndNotOverriden fails, resulting in
the aforementioned '... is overloaded on ... ' error messages.
So, can anyone explain this logic to me? Couldn't the proper method
(in overloaded situations) be determined by looking at
Method.getDeclaringClass() and match it to the concrete class? Or
maybe some other form of introspection.
I'd also be happy to add a generic parameter to my base interface to
determine the return type of getId (e.g. IEntity<T>... T getId()).
Obviously, this doesn't work with the current RequestFactoryModel, but
would this situation be at least more "introspectable" and allow
RequestFactoryModel to more properly determine which method to use in
an overload situation?
Any thoughts or ideas are appreciated.
Thanks
-matt
On Oct 27, 12:00 pm, invinity <m...@gopitts.net> wrote:
> Hey all 1st post!
>
> I'm building my 1st app with 2.1.0.RC1 (in eclipse helios) and using
> the new RequestFactory to map my JPA (eclipselink) entities. Things
> were going fine during my initial buildout until I added a "Long
> getId()" method to each of my EntityProxy interfaces. After this I get
> a RuntimeException("Deferred binding failed for '<my RequestFactory
> interface>'") during onModuleLoad(). Looking at the development
> console reveals messages like the following for each of my EntityProxy
> interfaces...
>
> "Method <EntityProxy class name>.getId() is overloaded on <JPA entity
> classname>"
>
> In troubleshooting this, it seems as though this error results from my
> JPA entity class hierarchy. Basically, I have a base IEntity interface
> that defines a getId() method to be implemented by my entity classes.
> I also have a BaseEntity abstract class (that implements IEntity) from
> which most all of my concrete entity classes inherit.
>
> If I refactor my base interface+class to remove the getId() method
> (e.g. all entity classes still inherit from BaseEntity, but have their
> own getId() method), then the GWT module loads fine and everything
> seems to just work.
>
> Obviously, having a getId() method on a base-type allows for some nice
> convenience methods and such. So, this seems like a very typical
> design approach, but for some reason GWT doesn't like it. I'm assuming
> it has something to do with how the binding code introspects my JPA
> classes.
>
> Maybe I'm missing something but it feels like having an abstract-base-
> type getId() method should be supported. Also, I don't see these
> errors with the getVersion() method that is defined in IEntity and
> implemented in BaseEntity, so I'm thinking it's something specific to
> the getId() method.
>
> I could probably put together a test app for it, if necessary, but I
> hope this explanation paints enough of a picture. Here is a basic
> sample of the class structure I've got...
>
> interface IEntity
> {
> Object getId();
> Integer getVersion();
>
> }
>
> abstract class BaseEntity implements IEntity
> {
> Integer version;
> public Integer getVersion() { return version; }
>
> }
>
> @Entity
> class RealEntity extends BaseEntity
> {
> Long id;
> public Long getId() { return id; }
>
> }
>
> TIA,
> -matt
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment