[hibernate-commits] [hibernate/hibernate-validator] 7867dc: HV-564 Adding some more methods to CollectionHelpe...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/hibernate/hibernate-validator
  Commit: 7867dcf2fb46cd200c91369abce825c20bb9b280
      https://github.com/hibernate/hibernate-validator/commit/7867dcf2fb46cd200c91369abce825c20bb9b280
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/internal/util/CollectionHelper.java
  A engine/src/main/java/org/hibernate/validator/internal/util/ReadWriteMap.java

  Log Message:
  -----------
  HV-564 Adding some more methods to CollectionHelper and introducing readWriteMap which has better performance than Collections#synchoronizedMap


  Commit: 832b84ad6b71c7f4eb16ebc0199dd16e44986246
      https://github.com/hibernate/hibernate-validator/commit/832b84ad6b71c7f4eb16ebc0199dd16e44986246
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/internal/engine/ConstraintTree.java
  A engine/src/test/java/org/hibernate/validator/test/internal/engine/ConstraintValidatorCachingTest.java

  Log Message:
  -----------
  HV-564 Removing the restriction that ConstraintValidator instances are only cached for the Hibernate internal ConstraintValidatorFactory.

Also removing the concept of ValidatorCacheKey. I don't think this was ever needed. As long as we have the same ValidatorFactory we will also have the same ConstraintValidatorFactory is used.
Reducing the memory footprint by removing some of the addtional maps.


  Commit: d6590605574aa037a6be3a7af080ca6844c423d1
      https://github.com/hibernate/hibernate-validator/commit/d6590605574aa037a6be3a7af080ca6844c423d1
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/test/java/org/hibernate/validator/test/internal/engine/ConstraintValidatorCachingTest.java

  Log Message:
  -----------
  HV-564 Making sure we don't have a regression against HV-243


  Commit: 9b6349068cbb313322ff100646256a35dc123dde
      https://github.com/hibernate/hibernate-validator/commit/9b6349068cbb313322ff100646256a35dc123dde
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/internal/engine/ConstraintTree.java
  M engine/src/test/java/org/hibernate/validator/test/internal/engine/ConstraintValidatorCachingTest.java

  Log Message:
  -----------
  HV-564 Reintroduced a ConstraintValidatorCacheKey since it is possible to have multiple constraint validator factories via ValidatorFactory#usingContext.

The cached is currently only bound by size which means the entries cached are hard references. For BV 1.1 we need to make some changes to cater for the new ConstraintValidatorFactory life cycle methods


  Commit: 33e1d3ad59c96120dddfe4e9e4a4ba87d2f147c1
      https://github.com/hibernate/hibernate-validator/commit/33e1d3ad59c96120dddfe4e9e4a4ba87d2f147c1
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/internal/engine/ConstraintTree.java

  Log Message:
  -----------
  HV-564 Actually SoftLimitMRUCache seems to be an even better fit as cache in this situation


  Commit: 76d92d811c53bb5551167a264ac27d4040b6478f
      https://github.com/hibernate/hibernate-validator/commit/76d92d811c53bb5551167a264ac27d4040b6478f
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/internal/metadata/BeanMetaDataManager.java
  A engine/src/test/java/org/hibernate/validator/test/internal/metadata/BeanMetaDataManagerTest.java

  Log Message:
  -----------
  HV-564 Actually not a ConstraintValidatorFactory test, but it shows that SoftLimitMRUCache works using BeanMetaDataManager.

We might need to disable this test in case some people report problem.


  Commit: dd421fbb93bb654d3d45bf6f213407018cd5e1ba
      https://github.com/hibernate/hibernate-validator/commit/dd421fbb93bb654d3d45bf6f213407018cd5e1ba
  Author: Hardy Ferentschik <hibernate at ferentschik.de>
  Date:   2012-04-03 (Tue, 03 Apr 2012)

  Changed paths:
    M engine/src/main/java/org/hibernate/validator/HibernateValidatorConfiguration.java
  M engine/src/main/java/org/hibernate/validator/internal/engine/ValidatorFactoryImpl.java
  M engine/src/main/java/org/hibernate/validator/internal/metadata/BeanMetaDataManager.java
  M engine/src/main/java/org/hibernate/validator/internal/util/logging/Log.java
  M engine/src/test/java/org/hibernate/validator/test/internal/metadata/BeanMetaDataManagerTest.java

  Log Message:
  -----------
  HV-479 Amendment. Using an explicit (lower) limit for soft and hard references in BeanMetaDataManager. Also making it possible to pass a hint (property) to HV to configure hard and soft limit. So far undocumented and experimental.


Compare: https://github.com/hibernate/hibernate-validator/compare/f1d6e43...dd421fb