On 2011/06/28 15:52:56, bobv wrote:
Regarding the 5926 case, were any of those methods defined in
unchecked proxies
or RequestContexts? I just want to make sure the problem is really
fixed the
first time around.
Unless I missed the warnings, they were correctly checked.
The RequestContexts were all unchecked, as our @ServiceName don't point
to the correct domain class (we're using a naming convention, automated
in a ServiceLayerDecorator, and I haven't yet took the time to fix the
annotation and remove the SLD; and even if they were, the service
classes are not in the same project and wouldn't be on the classpath
–proxies and requestcontexts are in our 'shared' project, which depends
on a 'model' project containing our domain objects, and the service
implementations are all in the 'server' project, which depends on
'shared'–)
Thanks for testing this out.
I'll try out the new patchset tomorrow (UTC+2) and will test a few cases
of bridge methods.
Our exact use case is, basically:
abstract class Abstract<T extends AbstractOther> {
public abstract T getOther();
public abstract void setOther(T other);
...
}
class Concrete1 extends BaseDomain<ConcreteOther1> {
private ConcreteOther1 other; // with getter/setter
}
class Concrete2 extends BaseDomain<ConcreteOther2> {
private ConcreteOther2 other; // with getter/setter
}
and the proxies:
@ProxyFor(value=Abstract.class, locator=...)
interface AbstractProxy extends EntityProxy {
// only used for server->client
...
}
@ProxyFor(value=Concrete1.class, locator=...)
interface Concrete1Proxy extends AbstractProxy {
ConcreteOther1Proxy getOther();
void setOther(ConcreteOther1Proxy other);
}
@ProxyFor(value=Concrete2.class, locator=...)
interface Concrete2Proxy extends AbstractProxy {
ConcreteOther2Proxy getOther();
void setOther(ConcreteOther2Proxy other);
}
The getters and setters in the domain classes are generated with bridge
methods, and RFIV sees them as overloads (so we're using a
ServiceLayerDecorator that totally bypasses the RFIV). I can't remember
what the exact issue was with the deferred-binding generator, but it
lead us to make the AbstractProxy non-generic, with no relationship to
the "other" property.
FYI, our proxies are automatically generated from our domain classes
(the generator runs on each build of the 'shared' project, scanning the
whole 'model' project for classes extending one of our base classes) so
it's relatively easy to tweak the mapping if necessary.
http://gwt-code-reviews.appspot.com/1467804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
