Thinking a bit more about it, this fix is IMO not enough: it will only
resolve properties that have not yet been resolved, which means in the
case of two methods returning the same object, if the second method
modifies some properties of the object before returning it and those
properties have already been resolved for the first method call, the
changes won't be visible to the client.
Imagine something like:
assertEquals(42, counter.getValue());
context.incrementAndReturnSelf().using(counter);
context.incrementAndReturnSelf().using(counter).to(new
ReceiverCounter() {
@Override
public void onSuccess(CounterProxy response) {
assertEquals(44, response.getValue()); // - expected=44,
actual=43
}
});
I haven't tried it, just braindumping the idea here, but because value
would have been resolved in response to the first call, it would be
ignored in the second call, and the AutoBeanCounterProxy would still
hold the first value (43).
So, either Resolver (or its internal state) would have to be scoped to
an invocation (rather than a Request), or resolveClientValue would have
to be deferred to createReturnOperations, with processInvocationMessages
only returning domain values. I'd be in favor of the second solution,
as it'd make the processing symmetric with the processOperationMessages
phase (which first getBeansForPayload and then applies the operations).
This can be seen as a different issue though (affects value properties
too, which are unconditionally resolved), and this patch is still needed
for the other case where the same object is returned at different
paths in the same incovation.
http://gwt-code-reviews.appspot.com/1377804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
