Jan and I further looked into the issue and actually found a working
solution that is less hacky than Eric's.
private void setupRequest(UserRequest request, UserProxy proxy) {
final UserProxy editableProxy = request.edit(proxy);
editorDriver.edit(editableProxy, request);
Is there any progress on this issue?
Issue https://code.google.com/p/google-web-toolkit/issues/detail?id=5794 is
related and is not fixed either.
RF's behaviour in this regard is inconsistent since an unimportant
retrieval would fail on any ConstraintViolation
in batched requests. It should
On Tuesday, November 26, 2013 1:56:35 PM UTC+1, Jan Marten wrote:
Is there any progress on this issue?
Issue https://code.google.com/p/google-web-toolkit/issues/detail?id=5794 is
related and is not fixed either.
RF's behaviour in this regard is inconsistent since an unimportant
The inconsistency with the current RequestFactory is that if in a batch
request, a single sub-request has a constraint violation
then onConstraintViolation is called for every sub-request and the whole
batch request fails (onFailure is called).
Whereas if in a sub-request an exception is raised
On Tuesday, November 26, 2013 4:10:08 PM UTC+1, Jan Marten wrote:
The inconsistency with the current RequestFactory is that if in a batch
request, a single sub-request has a constraint violation
There's no inconsistency, because that's not how things work.
1. All objects (entities and
Thank you for clarifying the behavior.
Nevertheless, in my opinion there is a use-case where the data should be
reusable after a server failure.
SQL exceptions like a unique constraint violation could be checked before
sending the request but
there might be server failures like a
I don't disagree. A non-reachable database is likely to trigger a global
failure though (in steps 1 or 4 from my previous message), that, IIRC
should make the RequestContext reusable (it does in some cases, I just
can't remember which ones)
That said, you could also handle the error on the
I'm running into this issue too. It seems when the server throws an
exception it gets sent to the individual Request not the fail() method in
the RequestContext. So reuse() is never called from it in the case of a
server exception. I'm not sure why they designed it this way. A server
Kevin,
My solution was to make copies of both RequestFactoryServlet and
SimpleRequestProcessor in a com.google.web.bindery.requestfactory.server
package in my environment, and then inside
MySimpleRequestProcessor.process(), add the following change:
.
.
.
assert
RF invocations are batched in a single HTTP request, but there's no implied
transaction. You're free to use a transaction-per-HTTP-request scheme, or a
transaction-per-invocation one (or no transaction at all). So when an
invocation fail, RF doesn't assume the whole batch can be sent again.
It looks like the onFailure case only unfreezes the context in the case of
onTransportFailure or response.getGeneralFailure, not in the case of an
invocation failure. I tested this, and the context is still locked and the
beans still frozen when my onFailure callback is called.
I guess I'll
Hmm, I tried going down the onViolation / onFailure paths, but ran in to
other problems with those.
For onFailure, is there a way to send a valueProxy back inside the exception
payload? It looks like the default behavior is just to extract the message
out of any thrown exception. I'd like to
Does anyone know of a way to perform the following scenario?
1. Retrieve an EntityProxy
2. Edit the proxy in an editor
3. Submit the changes using a Request Context
4. The server call is rejected due to a server-side validation failure
5. Make some more changes to the proxy
6.
On Thursday, July 28, 2011 11:55:54 PM UTC+2, Eric Andresen wrote:
Does anyone know of a way to perform the following scenario?
1. Retrieve an EntityProxy
2. Edit the proxy in an editor
3. Submit the changes using a Request Context
4. The server call is rejected due to a
14 matches
Mail list logo
