Refactor BeanMetaDataImpl
-------------------------
Key: HV-441
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-441
Project: Hibernate Validator
Issue Type: Task
Components: engine
Reporter: Hardy Ferentschik
Fix For: 4.x
Due to the introduction of method level validation the {{BeanMetaDataImpl}} abstraction
started leaking. For example parts of the configuration data is now held at multiple
places. We have to start addressing this and pull things together again.
I started a discussion around this with Gunnar. My original question was:
{quote}
Could you have a look at my branch
https://github.com/hferentschik/hibernate-validator/commits/HV-433. The tests for this
issue are passing (CascadingWithConstraintMappingTest), in fact the whole test suite is
passing. The problem I encountered was around MethodMetaData and its cascading flag. In
the case of the test case it was not properly set. The code was just looking for the
@Valid annotation, but also has to check whether the method is explicitly (xml or
programmatic api) configured for cascading.
If you have a look at the branch you see how I changed that. The question which came up in
my mind is, whether there is not duplication between MethodMetaData and BeanMetaData (at
least regarding the cascading).
{quote}
Gunnar's response:
{quote}
Yes, that's certainly right. Actually I'm not quite happy with BeanMetaDataImpl
altogether atm. It is pretty complex code, is quite huge and I think we should tidy
up/restructure it for 4.3.
When implementing method validation I found that the meta model was not expressive enough
for the new method stuff, which was why I came up with more powerful model classes
accompanying BeanMetaData such as MethodMetaData and ParameterMetaData. The idea was that
the engine (ValidatorImpl) could simply ask a MethodMetaData whether it requires cascaded
validation or not for instance. At the same time I tried to to modify existing
functionality in BeanMetaDataImpl not more than necessary. So currently the situation is,
that method validation is based on MethodMetaData#isCascading(), while standard
bean/property validation relies on BeanMetaDataImpl#cascadingMembers. In BMDI's
constructor both structures are maintained.
Actually I'm proceeding on that path for HV-371. There I introduced
AggregatedMethodMetaData which represents a given method *and* all the methods up in the
hierarchy which it overrides/implements (basically this replaces the
Map<Class<?>, Map<Method, MethodMetaData>> methodMetaConstraints with
Map<Method, AggregatedMethodMetaData> methodMetaData. This should make things much
easier in ValidatorImpl, which now can deal with one AggregatedMethodMetaData object
instead of iterating over the complete inheritance hierarchy (So for instance
AMMD#isCascading() answers whether a cascaded validation is required for the given method
no matter where in the hierarchy it was marked with @Valid).
So I definitely think we should get these things more aligned again but I've got the
feeling we can live with the situation temporarily. WDYT?
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira