<div><div>hi thang,</div><div><br></div><div>bv 1.1 allows to use cdi beans as constraint-validators.</div><div>(for bv 1.0 you can use add-ons like the bv module of [1] or [2].)</div><div><br></div><div>-> you can use any scope you need.</div>
<div><br></div><div>regards,</div><div>gerhard</div><div><br></div><div>[1] <a href="http://myfaces.apache.org/extensions/cdi/">http://myfaces.apache.org/extensions/cdi/</a></div><div>[2] <a href="http://deltaspike.apache.org">http://deltaspike.apache.org</a></div>
<div><br></div><br><br><div class="gmail_quote">2013/6/12 Thang Le <span dir="ltr"><<a href="mailto:thangmle@gmail.com" target="_blank">thangmle@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div>Hi all,<br><br></div>I've come across a scenario which makes me think supporting different scopes for custom constraint validators would ease the task for writing efficient validation logic. Similar to Spring IoC, these scopes are prototype, session & singleton. Currently, the Bean Validation 1.1 spec suggests a 'prototype' scope should be used for all custom constraint validation classes. In my opinion, the 'session' (likely singleton as well) scope proves to be useful when a custom constraint validator needs to do the SAME timing pre-processing logic before doing some actual validation logic on the current targeted object. In such cases, the developer would want to store the result of the pre-processing logic into an instance variable of the custom constraint validation class and reuse this result later when the constraint is executed again on different objects. Below is a specific use-case from my current project.<br>
<br></div>The model I need to validate has a tree-like structure. In this model, each node can be a/an remote/access-point/cluster. I have a model builder which builds the model tree given a set of nodes. The builder then hands off this tree to the validator to validate it. I have some constraints which require to check the uniqueness of a certain property for a set of nodes (e.g: all access-points in the tree must have unique serial number). These constraints are written as custom constraints. I recognize these constraints follow the same pattern which is I need to traverse the tree to collect all required node and build a multimap out of the collected nodes and check for uniqueness using the key of the current targeted object. For above example, the custom constraint is a class constraint of access-point class. I need to collect all access-points in the tree, build a multimap of <serialNumber:access-point> pairs. Then I lookup from the map the collection of access-points based on the serial number of the access-point being validated. It would be beneficial if the multimap of <serialNumber:access-point> pairs can be stored in the custom validator so that I don't need to re-do this expensive task again when validating other access-points.<br>
<br></div>There might be some reasons that you wouldn't want to support different scopes for custom constraint validator. However, I would think when it comes to writing a constraint for a bean in relation with other beans, such scopes become handy. Please let me know your thoughts on this feature. <br>
<span class="HOEnZb"><font color="#888888">
<br></font></span></div><span class="HOEnZb"><font color="#888888">Thang<br><div><div><div><div><div><br><br></div></div></div></div></div></font></span></div>
<br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br></blockquote></div><br></div>