7:44 a.m.
Hey Linda,
What do you think about that in principle?
We were discussing whether or not BV should describe what CDI integration it has, Gunnar
found out that some integration descriptions are in the Java EE umbrella spec.
It made sense at the time but we are thinking now that we should bring back that kind of
information "in-house" and have a Java EE integration chapter inside the BV
spec.
That would mean that we need to remove part of section EE 6.27 and probably point to the
BV chapter instead. Does that make sense to you? It seems to be the way of things in the
EE sphere these days and centralizing the info for a given technology seem to make sense.
Emmanuel
On 22 août 2012, at 22:13, Gunnar Morling wrote:
Hi,
In addition to the things to be added with BV 1.1, I think we should
also have a look at BV-related sections which are part of the Java EE
spec as of today.
More specifically, the Java EE spec says in section EE.6.27 on the
integration of BV and JSF/JPA:
"The Java EE platform requires that web containers make an instance of
ValidatorFactory available to JSF implementations by storing it in a
servlet context attribute named
javax.faces.validator.beanValidator.ValidatorFactory.
The Java EE platform also requires that an instance of
ValidatorFactory be made available to JPA providers as a property in
the map that is passed as the second argument to the
createContainerEntityManagerFactory(PersistenceUnitInfo, Map) method
of the PersistenceProvider interface, under the name
javax.persistence.validation.factory."
If we're going to describe the integration of BV and CDI within the BV
spec, I guess it would make sense that this section goes there as well
to be consistent. WDYT?
--Gunnar
2012/8/22 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> I'm sure there will be a next call soon, bring me in and we can discuss the issue
at large :)
>
> On 22 août 2012, at 14:37, Pete Muir wrote:
>
>> Can you sync with Linda or Bill direct, as it really was just mutterings as you
weren't on the call ;-)
>>
>> On 22 Aug 2012, at 13:34, Emmanuel Bernard wrote:
>>
>>> Of of the options is to have it defaulted to enabled. To disable validation
or change the default group, @MethodValidated would be necessary.
>>> Is that what the EE spec leads had in mind?
>>>
>>> On 22 août 2012, at 13:23, Pete Muir wrote:
>>>
>>>> BTW the Java EE spec leads were concerned about the @MethodValidated
annotation being required at all.
>>>>
>>>> On 22 Aug 2012, at 12:19, 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
>>>>>> [1].
>>>>>>
>>>>>> 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
>>>>>> [2] 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 [3]. So I guess our descriptions there need just to
be a
>>>>>> bit more authoritative ("must" instead of
"should" etc.) and specific.
>>>>>> 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 5.5.7.1.
>>>>>>
>>>>>> The same approach should probably also be taken for the
description of
>>>>>> triggering method validation under Java EE using the
@MethodValidated
>>>>>> annotation.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>> [1]
http://lists.jboss.org/pipermail/cdi-dev/2012-August/001978.html
>>>>>> [2]
http://lists.jboss.org/pipermail/cdi-dev/2012-August/002045.html
>>>>>> [3] http://beanvalidation.org/1.1/spec/#d0e6698
>>>>>> _______________________________________________
>>>>>> 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