I don't know why, but it outputs an error twice (this is the only
"missing ProxyFor annotation" I have, so I can't tell whether it's
specific to that interface or more general):
myapp-shared/src/main/java/xxx/shared/breadcrumb/BreadCrumbItemProxy.java:14:
A proxy must be annotated with ProxyFor, ProxyForName, or JsonRpcProxy
public interface BreadCrumbItemProxy<T extends Enum<T> & FieldEnum<T>>
extends BaseEmbeddedValueProxy {
^
myapp-shared/src/main/java/xxx/shared/breadcrumb/BreadCrumbItemProxy.java:14:
A proxy must be annotated with ProxyFor, ProxyForName, or JsonRpcProxy
public interface BreadCrumbItemProxy<T extends Enum<T> & FieldEnum<T>>
extends BaseEmbeddedValueProxy {
^
BTW, this is a case I could push the "extends" down to subinterfaces
(having 4 proxies implementing the same "mixin", rather than 4
interfaces extending the same proxy bae interface)
===============
Another error should IMO be a warning:
myapp-shared/src/main/java/xxx/shared/LockInfoProxy.java:10: Could not
find domain method similar to xxx.AbstractLockableEntity
findAbstractLockableEntity(java.lang.String)
public interface LockInfoProxy extends EntityProxy, LockInfo {
^
This is expected, we only send LockInfoProxy down from the server to the
client, so we don't need the findXxx. In comparison, the lack of a
zero-arg constructor is only a warning:
myapp-shared/src/main/java/xxx/shared/breadcrumb/DossierBreadCrumbItemProxy.java:13:
warning: The domain type xxx.model.breadcrumb.DossierBreadCrumbItem has
no default constructor. Calling
RequestContext.create(DossierBreadCrumbItemProxy.class) will cause a
server error
It would be easy to workaround (use a Locator or put a dummy findXxx
method in the domain class) but still, I think it's a bug to flag this
as an error (it's admittedly a "strong warning", as you could very
easily fall in the trap, much more than a missing zero-arg constructor,
but I don't think it's an error that should break the build).
====
Finally, I have a small issue with generics, but I believe it's my
fault: a List<SubFooProxy> getItems() in the proxy interface, but a
List<? extends BaseFooProxy> getItems() in the domain class, and
RfValidator generates an error that it cannot find the domain method.
http://gwt-code-reviews.appspot.com/1467804/diff/6052/user/src/com/google/web/bindery/requestfactory/apt/DomainChecker.java
File
user/src/com/google/web/bindery/requestfactory/apt/DomainChecker.java
(right):
http://gwt-code-reviews.appspot.com/1467804/diff/6052/user/src/com/google/web/bindery/requestfactory/apt/DomainChecker.java#newcode340
user/src/com/google/web/bindery/requestfactory/apt/DomainChecker.java:340:
state.warn(warnTo, "Cannot validate method (%s.%s) because the domain
mapping for the"
On 2011/06/30 15:16:48, bobv wrote:
This is more verbose, but it will unambiguously identify the unchecked
method in
question.
This doesn't print what one would expect:
myapp-shared/src/main/java/xxx/shared/BaseEmbeddedProxy.java:16:
warning: Cannot validate method
(xxx.shared.xxx.xxx.XxxProxy.()com.atolcd.gertrude.production.shared.EmbeddedProxyId)
because the domain mapping for the return type
(xxx.shared.EmbeddedProxyId) could not be resolved to a domain type
Add @SuppressWarnings("requestfactory") to dismiss.
EmbeddedProxyId getId();
^
There's no mention of 'getId' in the message.
Note that I changed the way I launch the apt (calling 'javac -proc:only'
from the command line, rather tha using a Maven plugin) and the output
is different, and actually references the exact location of the warning;
so in the end, I don't think this change is necessary (sorry)
It appears I wasn't clear on my previous "report" though, and this
output format makes it even clearer: this warning is output once for
each interface extending BaseEmbeddedProxy, each time for the exact same
location (notice the beginning of the line, it points to
BaseEmbeddedProxy.java:16, where the getId method is defined).
Further more, the EmbeddedProxyId cannot be resolved because of this
earlier warning:
myapp-shared/src/main/java/xxx/shared/EmbeddedProxyId.java:12: warning:
Cannot fully validate proxy since type xxx.server.EmbeddedId is not
available
Add @SuppressWarnings("requestfactory") to dismiss.
public interface EmbeddedProxyId extends ValueProxy {
^
because the xxx.server.EmbeddedId is in the myapp-server project, which
depends on myapp-shared and therefore is not available at the time we
compile myapp-shared.
I don't mind having the warning on the getId method because of a
previous warning on EmbeddedProxyId, but there should IMO be only one,
not hundreds of them! (I actually have 52 such warnings exactly)
http://gwt-code-reviews.appspot.com/1467804/diff/6052/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java
File
user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java
(right):
http://gwt-code-reviews.appspot.com/1467804/diff/6052/user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java#newcode102
user/src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java:102:
return state.types.erasure(t).accept(this, state);
Have you tried with an intersection type? i.e. something like <T extends
MyInterface & EntityProxy>
I don't have that in my code base, and haven't tried it, but judging
from the code of Eclipse's TypeVariableImpl#getUpperBound, it might very
well trigger the bug too, in which case erasure() probably wouldn't be
an appropriare workaround.
I was thinking about looping on the Types#directSupertypes until one is
detected as a "transportable type":
for (TypeMirror type : state.types.directSupertypes(t)) {
if (type.accept(this, state)) {
return true;
}
}
return false;
that should work, because the expected type of getUpperBound is a
DeclaredType, so visitDeclared should have been called, and it only uses
isAssignable checks (so isAssignable(MyInterface&EntityProxy,
EntityProxy) would be equivalent to
isAssignable(MyInterface,EntityProxy)||
isAssignable(EntityProxy,EntityProxy).
In the case of <T extends Enum<T>>, I guess it'd work the same.
}
http://gwt-code-reviews.appspot.com/1467804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
