I understand the consequences. I am not sure whether it is really such a good idea that
integration is described/specified in the technology specs, but if this is how others are
do it, we should be good citizens and do the same.
I also agree with Gunnar that we need to review some areas of the spec regarding the
On 22 Jan 2012, at 1:19 PM, Emmanuel Bernard wrote:
Yes, one of the consequences as you point out is that we will define
the @MethodValidated contract in BV.
While I think it's a good thing, I want everyone to understand this consequence.
On 15 août 2012, at 22:56, Gunnar Morling wrote:
> Hi all,
> based on an issue I recently filed, CDI lead Pete Muir started a
> thread on the integration of BV and CDI over on the CDI mailing list
> The general question is where this integration should be described. My
> first assumption was, that the Java EE platform spec. would be the
> right place for this is, but Java EE co-lead Bill Shannon pointed out
>  that the preferred approach is to have such integrations described
> in one of the involved technology specs.
> And actually we're already doing this to some degree as of the BV 1.1
> early draft . So I guess our descriptions there need just to be a
> bit more authoritative ("must" instead of "should" etc.) and
> In section 3.7, the CDI spec. currently also mentions built-in beans
> for Validator and ValidatorFactory to be provided by a Java EE
> container. To consolidate the specs I tend to think that this section
> should be merged into BV section 184.108.40.206.
> The same approach should probably also be taken for the description of
> triggering method validation under Java EE using the @MethodValidated
> Any thoughts?
>  http://lists.jboss.org/pipermail/cdi-dev/2012-August/001978.html
>  http://lists.jboss.org/pipermail/cdi-dev/2012-August/002045.html
>  http://beanvalidation.org/1.1/spec/#d0e6698