Purpose of JSR-BeanValidation in RequestFactory

[StefanR]

I wonder if the JSR 303 bean validation at the client-server-interface is really helpful. I stumbled upon two restrictions why I decided to deactivate the validation:

• Beans created within the client might be populated in the back-end. For instance, I have a @NotNull column which contains the creationDate of an entity. It doesn't make sense to let clients set this value, instead it is set just before persisting the first time.
• Beans object graph needs to be complete for relations with cardinality 1 or 1..n. Again a @NotNull association prevents partially filled beans to be send back to the server.

Opinions?

Regards,

Stefan.

[Eric Andresen]

I am having the same issue.  I need to do some pre-processing of my beans on the server before I fire validation, but the framework doesn't allow that.   It only fires validation on the beans as soon as they are decoded off the wire. As far as I can tell, the RequestFactory also doesn't give you hooks to fire your own validation later or to feed your own validation errors back into the onViolation callback.

[Jens]

On server side you can use a custom ServiceLayerDecorator and implement the validate method to customize the validation process (ReflectiveServiceLayer contains the default way of validaton).

In your bean you could use validation groups: the default one that is used by the client side code and an additional server validation group. In your ServiceLayerDecorator you would then validate against the server validation group. I think that way you should be able to allow null fields on client side but disallow them on server side.

-- J.