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>:
> 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