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 <ha...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
