2:40 p.m.
On Sat, Jan 7, 2012 at 6:27 AM, Gunnar Morling
<gunnar.morling(a)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?
Matt
--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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev