[bv-dev] Cleaning up Java EE spec and move BV specifics to the BV spec (was Re: Support DI within constraint validators)

[Linda DeMichiel]

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 at 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 at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>