[
http://opensource.atlassian.com/projects/hibernate/browse/HV-445?page=com...
]
Gunnar Morling commented on HV-445:
-----------------------------------
I think we can defer this to post 4.2. The chance that this really causes a problem seems
really low (basically the meta-data for a given type would have to be built up in parallel
by multiple threads in order to *potentially* cause issues). I guess it makes sense to
address that together with the general meta-model refactoring.
Ensure meta models are completely immutable
--------------------------------------------
Key: HV-445
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-445
Project: Hibernate Validator
Issue Type: Improvement
Components: engine
Reporter: Gunnar Morling
Fix For: 4.2.0.CR1
The internal meta model (BeanMetaDataImpl et al.) as well as the external one
(BeanDescriptorImpl et al.) should be completely unmodifiable, as they could potentially
be accessed from multiple threads at the same time.
I made some more fields final/unmodifiable with HV-371, but there are some places left
which I couldn't change easily and need some more consideration:
* ConstraintDescriptorImpl#compositionType
* ElementDescriptorImpl#constraintDescriptors
* BeanMetaDatImpl#cascadedMembers (could be made unmodifiable after initialization
instead of creating a new unmodifiable set with each call of getCascadedMembers()
When looking through the model I found it quite complex to find out which collection
fields are already unmodifiable and which not. I therefore thought about introducing a
marker annotation @Unmodifiable which could be used to document unmodifiable fields. WDYT?
--
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