Hi Pete, In the BV 1.1 early draft we're currently saying the following [1]: === Java EE should [...] enable Context and Dependency Injection (CDI) support to ValidatorFactory instances. In particular: 1) Let Validator and ValidatorFactory object be injectable. 2) Use a default ConstraintValidatorFactory implementation that returns CDI managed ConstraintValidator objects. The scope of these instances is dependent as the Bean Validation provider is responsible for them. 3) Provide CDI managed instances of ConstraintValidatorFactory, MessageInterpolator and TraversableResolver if customized classes are requested in the XML deployment descriptor. === I think that's pretty much in line with what you're saying. What caught my attention was section 3.7 of the CDI spec which mentions built-in beans for Validator and ValidatorFactory to be provided by an EE container. So this covers 1) from above, but not the others. I'm wondering now whether 2) and 3) should be mentioned there as well or whether the entire section should be moved to the Java EE spec (I think that's what you're saying?). --Gunnar [1] http://beanvalidation.org/1.1/spec/#d0e6698 2012/8/2 Pete Muir <pmuir(a)redhat.com&gt;: > Hi Emmanuel, Gunnar, > > Gunnar filed https://issues.jboss.org/browse/CDI-241 however I don't think we should reference this in the CDI spec. Instead, Bean Validation should declare which of it's classes should be "Java EE component classes", which then makes them eligible for injection by CDI. These types are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this relates to how we define what receives CDI injections going forward, as I'm not sure they want to continue with this method. > > Pete

Hi Pete, I can see your concerns, though I'm personally not really convinced of putting this into the BV spec either. I like the idea of BV providing services/functionality, which then can be leveraged by integration technologies such as CDI/JEE or e.g. Spring. Personally I feel we shouldn't refer to these integrating technologies in the BV spec. Wouldn't the JEE spec be the right place for defining the integrations between the different contained specs/technologies? Those wouldn't have to deal with such integration questions, could be used independently under SE and closely integrated under EE. Do you know whether there are any ideas already for using CDI within JPA entity listeners? I think this should be rather similar: a spec defines so-far unmanaged objects which should make use of CDI under EE. --Gunnar 2012/8/13 Pete Muir <pmuir(a)redhat.com&gt;: > Or, we could move that requirement from the CDI spec to the BV spec, and have BV cover it all... > > If we put too much into CDI, it ends up becoming an integration dumping ground, which doesn't work so well, IMO. > > On 5 Aug 2012, at 22:11, Gunnar Morling wrote: > >> Hi Pete, >> >> In the BV 1.1 early draft we're currently saying the following [1]: >> >> === >> Java EE should [...] enable Context and Dependency Injection (CDI) >> support to ValidatorFactory instances. In particular: >> >> 1) Let Validator and ValidatorFactory object be injectable. >> 2) Use a default ConstraintValidatorFactory implementation that >> returns CDI managed ConstraintValidator objects. The scope of these >> instances is dependent as the Bean Validation provider is responsible >> for them. >> 3) Provide CDI managed instances of ConstraintValidatorFactory, >> MessageInterpolator and TraversableResolver if customized classes are >> requested in the XML deployment descriptor. >> === >> >> I think that's pretty much in line with what you're saying. >> >> What caught my attention was section 3.7 of the CDI spec which >> mentions built-in beans for Validator and ValidatorFactory to be >> provided by an EE container. So this covers 1) from above, but not the >> others. >> >> I'm wondering now whether 2) and 3) should be mentioned there as well >> or whether the entire section should be moved to the Java EE spec (I >> think that's what you're saying?). >> >> --Gunnar >> >> [1] http://beanvalidation.org/1.1/spec/#d0e6698 >> >> >> 2012/8/2 Pete Muir <pmuir(a)redhat.com&gt;: >>> Hi Emmanuel, Gunnar, >>> >>> Gunnar filed https://issues.jboss.org/browse/CDI-241 however I don't think we should reference this in the CDI spec. Instead, Bean Validation should declare which of it's classes should be "Java EE component classes", which then makes them eligible for injection by CDI. These types are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this relates to how we define what receives CDI injections going forward, as I'm not sure they want to continue with this method. >>> >>> Pete >

I guess then the question is whether X is CDI or BV in this case. On 14 Aug 2012, at 01:10, Bill Shannon wrote: > I don't have enough background to evaluate the specific issue being > discussed here, but let me comment on the general issue of whether the > Java EE platform spec should be the place to define how all the component > technologies integrate with each other. > > Originally, that's more or less the approach we took, but it has proven > to be somewhat limiting. With more and more component technologies being > available independently of the platform, it's important to define how these > technologies work together even if they're not part of a Java EE product. > > Thus, we've moved to an approach that's more like this... In the spec > for technology X, we might have requirements of the form "when technology X > is included in a product that also includes technology Y, the following > additional requirements apply...." the advantage of this approach is that > you can tell how the pieces have to fit together in the many contexts where > they can be used. A disadvantage is that there's no longer the "master list" > of all the integration requirements. > > This approach works best when the integration points between specs are > fully defined by the specs. It works less well when the integration > points rely on product-specific interfaces. Fully defining all the > integration points for all our technologies is a huge task that we'll > probably never complete. And defining such integration points is often > less important than improving the application-visible APIs. We live in > a world of compromise with limited time and resources. > > > Gunnar Morling wrote on 08/13/12 13:42: >> Hi Pete, >> >> I can see your concerns, though I'm personally not really convinced of >> putting this into the BV spec either. >> >> I like the idea of BV providing services/functionality, which then can >> be leveraged by integration technologies such as CDI/JEE or e.g. >> Spring. Personally I feel we shouldn't refer to these integrating >> technologies in the BV spec. >> >> Wouldn't the JEE spec be the right place for defining the integrations >> between the different contained specs/technologies? Those wouldn't >> have to deal with such integration questions, could be used >> independently under SE and closely integrated under EE. >> >> Do you know whether there are any ideas already for using CDI within >> JPA entity listeners? I think this should be rather similar: a spec >> defines so-far unmanaged objects which should make use of CDI under >> EE. >> >> --Gunnar >> >> >> 2012/8/13 Pete Muir <pmuir(a)redhat.com&gt;: >>> Or, we could move that requirement from the CDI spec to the BV spec, and have BV cover it all... >>> >>> If we put too much into CDI, it ends up becoming an integration dumping ground, which doesn't work so well, IMO. >>> >>> On 5 Aug 2012, at 22:11, Gunnar Morling wrote: >>> >>>> Hi Pete, >>>> >>>> In the BV 1.1 early draft we're currently saying the following [1]: >>>> >>>> === >>>> Java EE should [...] enable Context and Dependency Injection (CDI) >>>> support to ValidatorFactory instances. In particular: >>>> >>>> 1) Let Validator and ValidatorFactory object be injectable. >>>> 2) Use a default ConstraintValidatorFactory implementation that >>>> returns CDI managed ConstraintValidator objects. The scope of these >>>> instances is dependent as the Bean Validation provider is responsible >>>> for them. >>>> 3) Provide CDI managed instances of ConstraintValidatorFactory, >>>> MessageInterpolator and TraversableResolver if customized classes are >>>> requested in the XML deployment descriptor. >>>> === >>>> >>>> I think that's pretty much in line with what you're saying. >>>> >>>> What caught my attention was section 3.7 of the CDI spec which >>>> mentions built-in beans for Validator and ValidatorFactory to be >>>> provided by an EE container. So this covers 1) from above, but not the >>>> others. >>>> >>>> I'm wondering now whether 2) and 3) should be mentioned there as well >>>> or whether the entire section should be moved to the Java EE spec (I >>>> think that's what you're saying?). >>>> >>>> --Gunnar >>>> >>>> [1] http://beanvalidation.org/1.1/spec/#d0e6698 >>>> >>>> >>>> 2012/8/2 Pete Muir <pmuir(a)redhat.com&gt;: >>>>> Hi Emmanuel, Gunnar, >>>>> >>>>> Gunnar filed https://issues.jboss.org/browse/CDI-241 however I don't think we should reference this in the CDI spec. Instead, Bean Validation should declare which of it's classes should be "Java EE component classes", which then makes them eligible for injection by CDI. These types are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this relates to how we define what receives CDI injections going forward, as I'm not sure they want to continue with this method. >>>>> >>>>> Pete >>> >

Hi, BVal should be able to get the bean manager so then CDI doesn't need to be BVal aware, no? the opposite is more invasive IMO - Romain 2012/8/14 Bill Shannon <bill.shannon(a)oracle.com&gt; > > I would guess BV, but it depends on the details. Which implementation > would need to change to implement the requirement? > > Pete Muir wrote on 08/14/12 03:59: > > I guess then the question is whether X is CDI or BV in this case. > > > > On 14 Aug 2012, at 01:10, Bill Shannon wrote: > > > >> I don't have enough background to evaluate the specific issue being > >> discussed here, but let me comment on the general issue of whether the > >> Java EE platform spec should be the place to define how all the > >> component > >> technologies integrate with each other. > >> > >> Originally, that's more or less the approach we took, but it has proven > >> to be somewhat limiting. With more and more component technologies > >> being > >> available independently of the platform, it's important to define how > >> these > >> technologies work together even if they're not part of a Java EE > >> product. > >> > >> Thus, we've moved to an approach that's more like this... In the spec > >> for technology X, we might have requirements of the form "when > >> technology X > >> is included in a product that also includes technology Y, the following > >> additional requirements apply...." the advantage of this approach is > >> that > >> you can tell how the pieces have to fit together in the many contexts > >> where > >> they can be used. A disadvantage is that there's no longer the "master > >> list" > >> of all the integration requirements. > >> > >> This approach works best when the integration points between specs are > >> fully defined by the specs. It works less well when the integration > >> points rely on product-specific interfaces. Fully defining all the > >> integration points for all our technologies is a huge task that we'll > >> probably never complete. And defining such integration points is often > >> less important than improving the application-visible APIs. We live in > >> a world of compromise with limited time and resources. > >> > >> > >> Gunnar Morling wrote on 08/13/12 13:42: > >>> Hi Pete, > >>> > >>> I can see your concerns, though I'm personally not really convinced of > >>> putting this into the BV spec either. > >>> > >>> I like the idea of BV providing services/functionality, which then can > >>> be leveraged by integration technologies such as CDI/JEE or e.g. > >>> Spring. Personally I feel we shouldn't refer to these integrating > >>> technologies in the BV spec. > >>> > >>> Wouldn't the JEE spec be the right place for defining the integrations > >>> between the different contained specs/technologies? Those wouldn't > >>> have to deal with such integration questions, could be used > >>> independently under SE and closely integrated under EE. > >>> > >>> Do you know whether there are any ideas already for using CDI within > >>> JPA entity listeners? I think this should be rather similar: a spec > >>> defines so-far unmanaged objects which should make use of CDI under > >>> EE. > >>> > >>> --Gunnar > >>> > >>> > >>> 2012/8/13 Pete Muir <pmuir(a)redhat.com&gt;: > >>>> Or, we could move that requirement from the CDI spec to the BV spec, > >>>> and have BV cover it all... > >>>> > >>>> If we put too much into CDI, it ends up becoming an integration > >>>> dumping ground, which doesn't work so well, IMO. > >>>> > >>>> On 5 Aug 2012, at 22:11, Gunnar Morling wrote: > >>>> > >>>>> Hi Pete, > >>>>> > >>>>> In the BV 1.1 early draft we're currently saying the following [1]: > >>>>> > >>>>> === > >>>>> Java EE should [...] enable Context and Dependency Injection (CDI) > >>>>> support to ValidatorFactory instances. In particular: > >>>>> > >>>>> 1) Let Validator and ValidatorFactory object be injectable. > >>>>> 2) Use a default ConstraintValidatorFactory implementation that > >>>>> returns CDI managed ConstraintValidator objects. The scope of these > >>>>> instances is dependent as the Bean Validation provider is > >>>>> responsible > >>>>> for them. > >>>>> 3) Provide CDI managed instances of ConstraintValidatorFactory, > >>>>> MessageInterpolator and TraversableResolver if customized classes > >>>>> are > >>>>> requested in the XML deployment descriptor. > >>>>> === > >>>>> > >>>>> I think that's pretty much in line with what you're saying. > >>>>> > >>>>> What caught my attention was section 3.7 of the CDI spec which > >>>>> mentions built-in beans for Validator and ValidatorFactory to be > >>>>> provided by an EE container. So this covers 1) from above, but not > >>>>> the > >>>>> others. > >>>>> > >>>>> I'm wondering now whether 2) and 3) should be mentioned there as > >>>>> well > >>>>> or whether the entire section should be moved to the Java EE spec (I > >>>>> think that's what you're saying?). > >>>>> > >>>>> --Gunnar > >>>>> > >>>>> [1] http://beanvalidation.org/1.1/spec/#d0e6698 > >>>>> > >>>>> > >>>>> 2012/8/2 Pete Muir <pmuir(a)redhat.com&gt;: > >>>>>> Hi Emmanuel, Gunnar, > >>>>>> > >>>>>> Gunnar filed https://issues.jboss.org/browse/CDI-241 however I > >>>>>> don't think we should reference this in the CDI spec. Instead, Bean > >>>>>> Validation should declare which of it's classes should be "Java EE component > >>>>>> classes", which then makes them eligible for injection by CDI. These types > >>>>>> are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this > >>>>>> relates to how we define what receives CDI injections going forward, as I'm > >>>>>> not sure they want to continue with this method. > >>>>>> > >>>>>> Pete > >>>> > >> > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

> I would guess BV, but it depends on the details. In the light of what you've been saying before about moving the description of integration points away from the Java EE spec to the individual technology specs this seems reasonable. Actually that's what we're basically already doing as of BV 1.1 early draft 1 as mentioned before [1]. Maybe the section just needs to get a bit more authoritative then. Although it might be a bit difficult for a Java EE implementor to find all integration requirements within the individual technology specs. Pete, should the note on built-in beans for Validator and ValidatorFactory from CDI spec. 3.7 be moved over to BV then? Let's see what Emmanuel thinks on this.

--Gunnar [1] http://beanvalidation.org/1.1/spec/#d0e6698 2012/8/14 Bill Shannon <bill.shannon(a)oracle.com&gt;: > I would guess BV, but it depends on the details. Which implementation > would need to change to implement the requirement? > > Pete Muir wrote on 08/14/12 03:59: >> I guess then the question is whether X is CDI or BV in this case. >> >> On 14 Aug 2012, at 01:10, Bill Shannon wrote: >> >>> I don't have enough background to evaluate the specific issue being >>> discussed here, but let me comment on the general issue of whether the >>> Java EE platform spec should be the place to define how all the component >>> technologies integrate with each other. >>> >>> Originally, that's more or less the approach we took, but it has proven >>> to be somewhat limiting. With more and more component technologies being >>> available independently of the platform, it's important to define how these >>> technologies work together even if they're not part of a Java EE product. >>> >>> Thus, we've moved to an approach that's more like this... In the spec >>> for technology X, we might have requirements of the form "when technology X >>> is included in a product that also includes technology Y, the following >>> additional requirements apply...." the advantage of this approach is that >>> you can tell how the pieces have to fit together in the many contexts where >>> they can be used. A disadvantage is that there's no longer the "master list" >>> of all the integration requirements. >>> >>> This approach works best when the integration points between specs are >>> fully defined by the specs. It works less well when the integration >>> points rely on product-specific interfaces. Fully defining all the >>> integration points for all our technologies is a huge task that we'll >>> probably never complete. And defining such integration points is often >>> less important than improving the application-visible APIs. We live in >>> a world of compromise with limited time and resources. >>> >>> >>> Gunnar Morling wrote on 08/13/12 13:42: >>>> Hi Pete, >>>> >>>> I can see your concerns, though I'm personally not really convinced of >>>> putting this into the BV spec either. >>>> >>>> I like the idea of BV providing services/functionality, which then can >>>> be leveraged by integration technologies such as CDI/JEE or e.g. >>>> Spring. Personally I feel we shouldn't refer to these integrating >>>> technologies in the BV spec. >>>> >>>> Wouldn't the JEE spec be the right place for defining the integrations >>>> between the different contained specs/technologies? Those wouldn't >>>> have to deal with such integration questions, could be used >>>> independently under SE and closely integrated under EE. >>>> >>>> Do you know whether there are any ideas already for using CDI within >>>> JPA entity listeners? I think this should be rather similar: a spec >>>> defines so-far unmanaged objects which should make use of CDI under >>>> EE. >>>> >>>> --Gunnar >>>> >>>> >>>> 2012/8/13 Pete Muir <pmuir(a)redhat.com&gt;: >>>>> Or, we could move that requirement from the CDI spec to the BV spec, and have BV cover it all... >>>>> >>>>> If we put too much into CDI, it ends up becoming an integration dumping ground, which doesn't work so well, IMO. >>>>> >>>>> On 5 Aug 2012, at 22:11, Gunnar Morling wrote: >>>>> >>>>>> Hi Pete, >>>>>> >>>>>> In the BV 1.1 early draft we're currently saying the following [1]: >>>>>> >>>>>> === >>>>>> Java EE should [...] enable Context and Dependency Injection (CDI) >>>>>> support to ValidatorFactory instances. In particular: >>>>>> >>>>>> 1) Let Validator and ValidatorFactory object be injectable. >>>>>> 2) Use a default ConstraintValidatorFactory implementation that >>>>>> returns CDI managed ConstraintValidator objects. The scope of these >>>>>> instances is dependent as the Bean Validation provider is responsible >>>>>> for them. >>>>>> 3) Provide CDI managed instances of ConstraintValidatorFactory, >>>>>> MessageInterpolator and TraversableResolver if customized classes are >>>>>> requested in the XML deployment descriptor. >>>>>> === >>>>>> >>>>>> I think that's pretty much in line with what you're saying. >>>>>> >>>>>> What caught my attention was section 3.7 of the CDI spec which >>>>>> mentions built-in beans for Validator and ValidatorFactory to be >>>>>> provided by an EE container. So this covers 1) from above, but not the >>>>>> others. >>>>>> >>>>>> I'm wondering now whether 2) and 3) should be mentioned there as well >>>>>> or whether the entire section should be moved to the Java EE spec (I >>>>>> think that's what you're saying?). >>>>>> >>>>>> --Gunnar >>>>>> >>>>>> [1] http://beanvalidation.org/1.1/spec/#d0e6698 >>>>>> >>>>>> >>>>>> 2012/8/2 Pete Muir <pmuir(a)redhat.com&gt;: >>>>>>> Hi Emmanuel, Gunnar, >>>>>>> >>>>>>> Gunnar filed https://issues.jboss.org/browse/CDI-241 however I don't think we should reference this in the CDI spec. Instead, Bean Validation should declare which of it's classes should be "Java EE component classes", which then makes them eligible for injection by CDI. These types are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this relates to how we define what receives CDI injections going forward, as I'm not sure they want to continue with this method. >>>>>>> >>>>>>> Pete >>>>> >>> >> >

On 14 Aug 2012, at 21:47, Gunnar Morling wrote: >> I would guess BV, but it depends on the details. > > In the light of what you've been saying before about moving the > description of integration points away from the Java EE spec to the > individual technology specs this seems reasonable. > > Actually that's what we're basically already doing as of BV 1.1 early > draft 1 as mentioned before [1]. Maybe the section just needs to get a > bit more authoritative then. Although it might be a bit difficult for > a Java EE implementor to find all integration requirements within the > individual technology specs. > > Pete, should the note on built-in beans for Validator and > ValidatorFactory from CDI spec. 3.7 be moved over to BV then? Let's > see what Emmanuel thinks on this. This would be good IMO. Gunnar, are you happy to raise this with Emmanuel/BV EG?