[cdi-dev] Support DI within BV constant validators

Tue Aug 14 16:57:54 EDT 2012

Hi,

when discussing the issue within the BV EG, the idea was to configure
a BV Validator(Factory) with a CDI-capable ConstraintValidatoryFactory
etc. That way BV doesn't directly interact with the CDI bean manager,
it just makes use of CDI-aware collaborators.

--Gunnar

2012/8/14 Romain Manni-Bucau <rmannibucau at gmail.com>:
> 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 at oracle.com>
>>
>> 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 at redhat.com>:
>> >>>> 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 at redhat.com>:
>> >>>>>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>