Hello all-- I'm just getting my feet wet with JSR-303. I started out using hibernate-validator, but as a foundation member and general connoisseur of Apache Kool-Aid I thought the very least I could do is give bval a fair shake. So far, just browsing code and javadocs--my typical way of acquainting myself with an OSS project--I'm impressed, FWIW.
What I want to do is expose all my validation information to my controller/view layers per the standard APIs, and here's the catch: *including* business-level validations which can be extremely dynamic in nature. To be more explicit, I am in the insurance industry, which (in the US anyway) consists pretty much entirely of "special cases." Firstly, is this considered out of scope of "Bean Validation" (the spec)? bval? If so, why?--It's my feeling that the spec intends that "validation" be quite an open-ended concept. A blanket "don't do this" would simply make me question the overall usefulness of the spec. However, it's obvious (at least, I *think* it is) that neither the annotation-based nor XML-based configuration methods can handle the dynamic application of constraints to a model. At the same time I want to be able to use those configuration methods for the subset of validations that *can* be handled so globally. I am thinking that I can reuse some of the underlying APIs from one of the existing Bean Validation implementations to maintain this dynamic information, then implement the ConstraintValidator for an e.g. @DynamicValidation annotation to reuse others' machinery. *This* I could configure in XML; best of both worlds. So to put this into bval terms, I could maintain a MetaBean graph for each distinct model graph and dynamically apply constraints per graph. This email has written itself in the sense that writing down my thoughts led to numerous edits and sculpted the above-outlined approach, which I'm tentatively feeling pretty good about, but I'd still like to get preliminary feedback from the community on the oh-shit level of the task I'm setting myself. Regards, Matt
