What I do not understand is: Why do we need to final JAX-RS 2.0 earlier than
the BV guys? Or in other words: If they can move their final date, why can't
we? What is so different in these two JSRs that we must keep our final date,
but BV does not?
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 19. Oktober 2012 12:42
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Bring back
> BeanValidation
>
> 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