Purpose of JSR-BeanValidation in RequestFactory

Skip to first unread message


Jul 29, 2011, 5:55:47 AM7/29/11
to google-we...@googlegroups.com
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.


Eric Andresen

Jul 29, 2011, 11:23:49 AM7/29/11
to google-we...@googlegroups.com
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.


Jul 29, 2011, 11:44:52 AM7/29/11
to google-we...@googlegroups.com
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.
Reply all
Reply to author
0 new messages