Re: [bv-dev] Ordered Validation (practically)
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.
--Gunnar
2012/1/6 Matt Benson <mbenson(a)apache.org>:
On Fri, Jan 6, 2012 at 11:11 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>
> On 5 janv. 2012, at 16:58, Matt Benson wrote:
>
>> On Thu, Jan 5, 2012 at 6:53 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>>>
>>> On 5 janv. 2012, at 13:44, Hardy Ferentschik wrote:
>>>
>>>>>
>>>>> Thanks for summing up.
>>>>
>>>> No problem. I will try to sum this up on beanvalidation.org asap as
well.
>>>
>>> Thanks, say you sum up BV-220 and BV-259 and I will sum up the other subjects
disccussed in the last few days. Lots of good content :)
>>
>> Guys,
>> Just to inject a little insanity into the debate... we've touched on
>> the idea of obtaining information in unorthodox ways before (parameter
>> names come to mind). Now, this proceeds from the assumption that a
>> given Java compiler would assemble bytecode such that visible
>> annotations would stay in the order in which they were defined, but
>> given that that is true for one or more available compilers, what is
>> the feeling of the community toward specifying that order be derived
>> from bytecode inspection? I realize this is quite specific, but in
>> the end nothing is more intuitive than just using the annotations in
>> the order in which they are actually specified.
>
> An alternative is to use annotation processors to capture source time information via
some kind of annotations but
> both approaches sound very scary.
> Matt do you think it's really worth exploring?
A little scary, yes. I think the annotation processing route is a
little *more* scary than the bytecode avenue... the least palatable
thing about it to me is that it places a heavy burden at the spec
level, constraining the implementations to do very specific things.
But I do find the bytecode examination idea interesting.
Matt
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev