[bv-dev] Method interception configuration and interception technology

[Emmanuel Bernard]

Here is a transcript of a chat I had with Pete on the subject.
Sorry for the typos. Basically, there is no way to host settings in
beans.xml so we need to have them in validation.xml. 
I'll sleep through the subject before coming up with a way but if you
ahve opinion, speak up :)

That raises also side questions around
https://hibernate.onjira.com/browse/BVAL-364

---

Pete Muir
about your email
basiclaly there is no way to configure this from beans.xml
i don't quite understand the problem? It's due to the fact you can't access validation.xml from the PE?

Emmanuel
you can
but we woul host a setting that the BV implementor would not make use of
which feels weird to me

Pete Muir
i don't understand "But it turns out that the portable extension is enabled at a different
tie than a ValidatorFactory. So using the programmatic API to change the
setting would not be reflected. Likewise, the portable extension would
need to read the validation.xml to find the setting."

Emmanuel
If as a user I do Validation.byDefaultProvider().configure().executableValidated(NON_GETTER_METHODS, CONSTRUCTOR).buildValidatorFactory()
then this setting will be ignored entirely

Pete Muir
why?
surely you just call into the BV config when you execute the intereceptor?

Emmanuel
Because the PE or the container specific way of binding interceptors and the right methods will have been executed way before

Pete Muir
as obviously the PE is executed at app start
which is something different to the way of starting BV

Emmanuel
Well not exactly, the initilal idea was not to do a noop when validateParameters etc are called even if they are supposed to be filtered because we wanted the binding to not intercept methods that don't need to be (to be faster)

Pete Muir
hmm, ok
well i don't think will work

Emmanuel
so the PE would need to know what the global etting is. Even worse it needs to take into account XML overriding for method level constraints
so somehow it needs to start a ValidatorFactory
even if it ditches it later on

Pete Muir
well unless you mandate that the VF is started at app start, then this won't work
or you provide a portable way to parse validation.xml
and extract this setting

Emmanuel
The global setting might be doable but not all the XML overriding approach (portable way). Ther eis a portable way but that's by starting a VF and calling upon its metadata API

Pete Muir
no, this is just an incompatibility between the java ee way, and the BV way
as you can start BV separately from the app deploy
i don't think that is resolvable really, it's just a different concept

Emmanuel
Not following you. You mean e cna't start the VF in the PE (or the proprietary way of wiring things)

Pete Muir
no i mean that most EE specs assume that the service (e.g. EJB, JSF, JAX-RS, CDI etc) start when the app deploys
so we integrate their startup process, and allow configuration integration
BV is different, because you can start it at any point

Emmanuel
ah yes ok got that
Well the injectable and lookupable VF /V are started at app start

Pete Muir
so you can't override a CDI startup setting from a BV startup setting

Emmanuel
(per EE rules)

Pete Muir
it's not possible
as the it doesn't happen at the same time
so the only way you can definitely do what you want is via validation.xml
programmatic, it will never work unless you make it a runtime noop in cdi
does that make sense

Emmanuel
I'm feverish so I'm not sure but I think so
"unless you make it a runtime noop in cdi" that I did not follow though
you mean a runtime noop when calling the validator right?

Pete Muir
i.e. you bind the interceptor
and in the interceptor you call ctx.proceed() immediately if the validator isn't required

Emmanuel
yes ok
But if we accept that rules defined in XML are the one used for method validation then I can do my optimization
(in this case I give up on the programmatic API option)
I don't want to over intercept for perf reason so I'm ready to compromise a here

Pete Muir
yes
agreed
i don't see another way, it's just not compatible
and it's all you would get in CDI *anyway*

Emmanuel
ok thanks for the chat, I have the data I needed I think. I'll paste this to the thread

On Wed 2013-01-23 17:30, Emmanuel Bernard wrote:
> Hi Pete,
> (I've added you as accepted sender to the mailing list so you can reply
> to beanvalidation-dev wo being rejected).
> 
> We have a problem and we need your wisdom.
> 
> ## Context
> 
> - Bean Validation offers method / constructor validation.
> - the feature is defined at a generic level to be implemented on all
>   interception technologies
> - we have a CDI specific section to make it clear how things work /
>   integrate with CDI
> - we need to be able to enable / disable validation for constructors,
>   non-getter and getter method both per element and via a global default setting
> 
> ## The problem
> 
> BV integrates with CDI via portable extensions (or some proprietary
> means similar to this) that bind an interceptor to the constructors and
> methods that require validation.
> 
> We offer @ValidateExecutable to customize whether or not a method /
> constructor is validated. And we also would like to offer a global
> setting.
> 
> We tried to make the validation configuration a core part of Bean
> Validation so that the logic would be similar across all interception
> technologies but we have hit a snag.
> 
> We wanted to make the global setting part of both:
> 
> - META-INF/validation.xml
> - the BV bootstrap API (programmatic approach)
> 
> But it turns out that the portable extension is enabled at a different
> tie than a ValidatorFactory. So using the programmatic API to change the
> setting would not be reflected. Likewise, the portable extension would
> need to read the validation.xml to find the setting.
> 
> that made some members of this group to push for having the method
> interception setting in a CDI configuration rather than Bean Validation
> one. Most likely beans.xml.
> 
> Is it a natural fit for CDI to augment beans.xml it with Portable Extension
> specific options and what is the way of doing it?
> We can try and keep things in validation.xml but that would be a
> placeholder that would need to be read one way or another by the
> interception technology.
> 
> What are your thoughts Pete?
> 
> Emmanuel
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev