[cdi-dev] Support DI within BV constant validators

Romain Manni-Bucau rmannibucau at gmail.com
Tue Aug 14 15:05:13 EDT 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20120814/adef8385/attachment.html 


More information about the cdi-dev mailing list