BV 1.0 exists and is final, so your argument is invalid. The proposed
integration is simple, only for Java EE environments, and is not BV
version dependent.
On 10/19/2012 6:41 AM, Marek Potociar wrote:
> Bill,
>
> Unless a specification is final, we cannot reference it in the spec. BV 1.1 will not be final before JAX-RS 2.0. So we cannot reference it in the spec. Which means that we would need to talk vaguely about "some" validation, which makes me wonder how useful such spec is. As for the suggestion to specify the integration as part of EE platform spec, I'm not convinced we should define JAX-RS specific algorithms outside of JAX-RS spec. That would make things just less transparent.
>
> We do have a plan to address this in a subsequent JAX-RS MR. We tried hard to convince the BV guys to move faster with their spec. We were told not to rush things. I do not think it's fair that they're now trying to rush it on our end by suggesting we adopt some half-baked solution that smells more like a workaround than a reasonable spec work to me.
>
> Marek
>
> On Oct 18, 2012, at 4:31 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>> I just conversed with the Bean Validation spec lead (Emmanuel) and he is quite upset that JAX-Rs no longer has bean validation integration. While I was a bit happy it was removed initially, because I don't want special classes for it, he convinced me otherwise.
>>
>> First and foremost, IMO, it should only be required in a Java EE environment and integration should be specified in the Java EE chapters of the 2.0 spec. Emmanuel defined this particular integration:
>>
>> 1. The resource fields and setters are injected
>> 2. fields and setters are validated and a HTTP 400 is returned on
>> failure to inject @Param injections. 500 for @Context
>> 3. method parameters are resolved
>> 4. method parameters are validated and a HTTP 400 is returned on failure to inject @Param, 500 for @Context
>> 5. method is executed
>> 6. method return value is validated and a HTTP 500 is returned on
>> failure
>>
>> The above does not require any special classes or binary dependencies on the validation spec. This sounds *very* reasonable to me. We require this in a Java EE environment only, IMO.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com