In OVal the advantage is, that we can control when an object is
instantiated. If I would leave that to e.g. Spring and rely on
ApplicationContext.getBean(...) it might be that Spring reuses objects
and gives me the same instance twice if wrongly configured (not as a
prototype bean).
Regards,
Seb
On 22.10.2011 10:46, Emmanuel Bernard wrote:
BTW, Sebastian, do you have a reason to still control the object
instantiation in OVal?
I wonder if there are any additional advantages besides the ability to
chain initialization listeners.
On 22 oct. 2011, at 10:39, Emmanuel Bernard <emmanuel(a)hibernate.org
<mailto:emmanuel@hibernate.org>> wrote:
> Indeed that's a typo for ConstraintViolationFactory.
>
> In your approach, the object cannot use constructor injection, correct?
> What does Spring Framework do in this case, raise an exception?
>
> On 22 oct. 2011, at 01:33, Sebastian Thomschke
> <sebastian.thomschke(a)web.de <mailto:sebastian.thomschke@web.de>> wrote:
>
>> Hi Emmanuel,
>>
>> the proposal talks about a ConstraintViolationFactory. I guess you
>> meant ConstraintValidatorFactory?
>>
>> In OVal dependency injection works like this: OVal instantiates the
>> validator (check) object itself and then passes it to an optional
>> CheckInitializationListener which can wire required dependencies. So
>> the DI system does not create the validator instances but configures
>> the dependencies.
>>
>> For Spring DI in OVal you do:
>> ClassPathXmlApplicationContext ctx = new
>> ClassPathXmlApplicationContext("SpringInjectorTest.xml",
>> SpringInjectorTest.class);
>> AnnotationsConfigurer myConfigurer = new AnnotationsConfigurer();
>> myConfigurer.addCheckInitializationListener(new
>> BeanInjectingCheckInitializationListener());
>> Validator v = new Validator(myConfigurer);
>>
>> Where the BeanInjectingCheckInitializationListener is implemented like:
>>
>> public class BeanInjectingCheckInitializationListener implements
>> CheckInitializationListener {
>> public void onCheckInitialized(final Check newCheck) {
>> // wire the dependencies
>> SpringInjector.get().inject(newCheck);
>> }
>> }
>>
>> For Bean Validation this could look like:
>> |ValidatorFactory factory = Validation
>> .byDefaultProvider()
>> .configure()
>> .addValidatiorInitializationListener(new
SpringBeanInjectingValidatorInitializationListener())
>> .buildValidatorFactory();
>>
>> Regards,
>>
>> Seb
>> |
>>
>> On 21.10.2011 23:55, Emmanuel Bernard wrote:
>>> Hi team,
>>> I've been thinking about BVAL-238 and came up with a first round of ideas
and open questions.
>>> It is available
herehttp://beanvalidation.org/proposals/BVAL-238/
>>>
>>> Please give me your feedback. I think this issue can be closed quite
quickly.
>>>
>>> I've also created a proposals section on the website that will contain
such work in progress proposals before inclusion in the spec proper. Check
outhttp://beanvalidation.org/proposals
>>>
>>> On a side note, for casual website editing, you can use GitHub's `Edit
this file` button
(
seehttps://github.com/beanvalidation/beanvalidation.org/blob/master/propo...
). It's not quite a wiki but that's pretty close. One thing you cannot do is
create a new file unfortunately. Anyone that have asked for write access should see this
button.
>>>
>>> Emmanuel
>>> _______________________________________________
>>> 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
>> <mailto:beanvalidation-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> <mailto:beanvalidation-dev@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