Handling Violations controlled by groups or Violations not found by default validation

[Michael Wiles]

I'm using GWT 2.5.0 and Request Factory.

I have configured a constraint to only apply on create (initial save) of my object.

This violation is not picked up by the default gwt request factory violation check mechanism - which kind of makes sense I guess, because it's in a group (I assume).

But it is thrown when I actually call my method.

So then what happens is that the violation exception is picked up as a server failure and not as a violation exception.

This is because in the SimpleRequestProcessor and method void process(RequestMessage req, ResponseMessage resp). The check violations is called before the method is invoked. This is fine, except that because my violation is in a group and I've configured it via this group to only apply on create the violation is not picked up. It is only picked up when the actually method is called.

And there is no check to see if the _method_ throws a violation exception and then to deal with any violation exceptions actually thrown by my method...

Would it not be possible to add a try catch around my method being called and dealing with these violations the same as the "normal" violation exceptions?

Or maybe somebody can tell me how to configure the gwt request processing to handle these violation exceptions and send them to the client as violation exceptions?

[Alex opn]

I just ran into the same issue. As there is no way to get or change the SimpleRequestProcessor im stuck now! Have you found out anything more, Michael Wiles?

[Jens]

By default, GWT calls validator.validate(domain) in ReflectiveServiceLayer.validate(), but you probably want 

if(domain.getId() == null) {

  return validator.validate(domain, CreateGroup.class);

}

return validator.validate(domain, Server/DefaultGroup.class);

You can do this by providing a custom ServiceLayerDecorator to RequestFactoryServlet and implement ServiceLayerDecorator.validate(T domain) accordingly.

-- J.

[Alex opn]

Thanks for your answer!

Well...propably I'm abusing bean validation (?), but in my case that doesn't help (actually I'm already doing it like this with different groups).

I'll try to explain my problem:

Basically I've got two validation groups which both should be run on the server-side: Client and Server

Client: These validators should be run when an object enters the server from the client (in the ServiceLayerDecorator)
Server: These validators should be run before persist / update etc happens (in my DAOs)

The reason why I separated it like this is that there are some class level constraints which may be violated when an object enters the server that should get corrected in the service method afterwards, but for safety be checked again before updating the database.

So far that works good and was pretty easy to implement:

ServiceLayerDecorator:

    @Override
    public <T> Set<ConstraintViolation<T>> validate(T domainObject) {
        return validator.validate(domainObject, Client.class);
    }

But ViolationExceptions occuring later are, as Michael already explained pretty well, reported as ServerFailures, not as ConstraintViolations -> non-resusable RequestContext, no error messages shown etc :-/

I already tried to copy/paste SimpleRequestProcessor & RequestFactoryServlet (into com.google... package structure) to change it to my needs. I have to admit though that I couldn't figure out how to catch all exceptions and not handle ConstraintViolationExceptions as server failures. I would already be happy with that although it feels a bit hacky :)!

[Thomas Broyer]

From the point of view of RF, these are just an exception thrown by the service method, like any other.

If you want to communicate failure to your client with specific information, then you have to make your service method return a response object containing the status (success/failure) and the details about the failure. onFailure is about *exceptional cases*, i.e. things that should *not* happen.

If it were me, I'd remove bean validation from RF entirely. It was useful when and meaningful when RF had optimistic locking (back in its really early days in the first GWT 2.1 milestones), but currently it's just confusing: because you send a diff, validation could fail not because you failed on the client-side, but because someone else modified a field that you didn't touch, and now conflicts with a field you modified on the client; now how do you fix that?

Keep RF automatic validation only for field-level syntactic / range validation, not for anything else; and for "business rules" inside service methods, they're just errors like any other, so treat them as such (see above)