[bv-dev] Ordered Validation (practically)

Gunnar Morling gunnar.morling at googlemail.com
Sun Jan 8 09:02:44 EST 2012


Hi,

personally I'm also not totally convinced of the byte code or the AP
approach. But leaving the door open for such alternatives would make
sense IMO.

> However, that excludes imo the explicit configuration of order, either via  Emmanuel's
> @GroupSequence.ordering=PER_TARGET or via a simple order property in the constraint itself.

Why would that be?

The (spec-mandated) default implementation of the order provider
contract could follow one of these approaches (which I also find way
more practical than the byte code/AP alternatives). But if a user
wishes to employ another ordering approach, she could use another
order provider implementation (e.g. by specifying it via the bootstrap
API) just as she could use another message interpolator etc.

--Gunnar

2012/1/8 Hardy Ferentschik <hardy at hibernate.org>:
> I am not so sure whether such a contract would be such a good idea. If we want to hold on to
> the byte code or annotation processor idea (if the latter is even possible), such a contract would
> make sense.
>
> However, that excludes imo the explicit configuration of order, either via  Emmanuel's
> @GroupSequence.ordering=PER_TARGET or via a simple order property in the constraint itself.
>
> As a user of BV I think I would rather prefer to directly see and hence be able to infer the order.
> And just imagine different  compilers actually do have different orders. That would be a total mess.
>
> --Hardy
>
>
> On Jan 7, 2012, at 9:40 PM, Matt Benson wrote:
>
>> On Sat, Jan 7, 2012 at 6:27 AM, Gunnar Morling
>> <gunnar.morling at googlemail.com> wrote:
>>> One idea might be to introduce some kind of "validation order
>>> provider" contract (similar to the parameter name provider we
>>> discussed recently) with a reasonable default implementation.
>>>
>>> BV providers could then come up with custom implementations based on
>>> byte code order, meta data pre-generated by an annotation processor
>>> etc. as they like which we still might spec later on if they proved
>>> useful.
>>
>> This sounds like a good compromise to transfer the responsibility from
>> the spec to the implementations for doing crazy things like reading
>> bytecode... so this would be a new collaborator managed for/by the
>> ValidatorFactory?
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



More information about the beanvalidation-dev mailing list