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

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