7:35 p.m.
Hi Emmanuel,
Bringing Bill into this discussion as well, for a second opinion....
Yes, I think what you are suggesting makes sense, certainly for the more detailed
integration requirements.
For example, that was the approach we took with JPA for the requirements on the container
for container-managed
persistence contexts-- the detailed requirements are in the JPA spec, including because
they complement the
other requirements that JPA imposes.
That said, what is currently in section EE 6.27 is very high level. Depending on what you
are planning
to add to the BV spec, it seems appropriate to me to keep some general statement of BV
requirements in
section EE 6.27 along with a forwarding pointer to the BV spec for specific requirements.
I'd have a better
idea of what I think should go there once I see your writeup though.
HTH,
-Linda
On 8/23/2012 5:44 AM, Emmanuel Bernard wrote:
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