Hi,
I think a good start for HV-439 would be to check for superfluous type
parameters. There a several parameterized methods in ValidatorImpl
which have unnecessary type parameters (mea culpa). I think
ValidatorImpl will look much simpler afterwards.
Regarding the ThreadLocal, I'm not sure. This would surely work, but
it would seem rather magic and hackish to me. It would introduce a
kind of global state and thus make understanding code and testing more
difficult, as it isn't obvious from a method's signature, that there
must exist some TL with certain state in order to invoke the method.
Couldn't we have one unified call context which is passed as parameter
on the stack?
--Gunnar
2012/1/10 Hardy Ferentschik <hardy(a)hibernate.org>:
Hi,
I was thinking about
https://hibernate.onjira.com/browse/HV-439 which basically also
means a
refactoring of the current ValidatorImpl.
One thing I noticed is that we start at one of the public Bean Validation methods and
then
create different context (e.g. ValueContext, ValidationConext) which we can passing
around
all the time, creating quite long method parameter lists.
Would it be a good idea to introduce a ThreadLocal here and pass the context information
this way?
It would definitely clean up the methods signatures. Thoughts?
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev