hferentschik

/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/bin/java -Didea.launcher.port=7533 "-Didea.launcher.bin.path=/Applications/Development/IDE/IntelliJ IDEA 11.app/bin" -Dfile.encoding=UTF-8 -classpath "/Applications/Development/IDE/IntelliJ IDEA 11.app/lib/idea_rt.jar:/Applications/Development/IDE/IntelliJ IDEA 11.app/plugins/junit/lib/junit-rt.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64/Contents/Home/jre/lib/ma

hferentschik

Cached:     /Users/hardy/work/hibernate/git/in.relation.to/_site/feed.atom
/Users/hardy/.rvm/rubies/ruby-1.9.3-head/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36: [BUG] object allocation during garbage collection phase
ruby 1.9.3p236 (2012-06-11 revision 36031) [x86_64-darwin11.4.0]

-- Control frame information -----------------------------------------------
c:0016 p:---- s:0049 b:0049 l:000048 d:000048 CFUNC  :require
c:0015 p:0053 s:0045 b:0045 l:000044 d:000044 METHOD /Users/hardy/.rvm/rubies/ruby-1.9.3-head/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36
c:0014 p:0095 s:0038 b:0038 l:000037 d:000037 TOP    /Users/hardy/.rvm/gems/[email protected]/gems/daemons-1.1.9/lib/daemons.rb:12
c:0013 p:---- s:0036 b:0036 l:000035 d:000035 FINISH
c:0012 p:---- s:0034 b:0034 l:000033 d:000033 CFUNC  :require

hferentschik

Good news for all of you waiting for an early version of Hibernate Validator 5 in order to experiment with the new Bean Validation 1.1 ([JSR 349](http://jcp.org/en/jsr/detail?id=349)) features. Hibernate Validator 5.0.0.Alpha1 is now available for download in the [JBoss Maven Repository](http://repository.jboss.org/nexus) under the GAV *org.hibernate:hibernate-validator:5.0.0.Alpha1* or via [SourceForge](http://sourceforge.net/projects/hibernate/files/hibernate-validator/5.0.0.Alpha1).

The focus of the release was the alignment of Hibernate Validator with the first [early draft](http://beanvalidation.org/1.1/) of Bean Validation 1.1 (1.1.0.Alpha1). The Hibernate Validator [changelog](https://hibernate.onjira.com/browse/HV/fixforversion/12051) circles for this reason around [HV-571](https://hibernate.onjira.com/browse/HV-571) which served as placeholder for those specification changes. Of course the biggest change was the formalisation of [method validation](http://beanvalidation.org/1.1/spec/#d0e2147), but t

hferentschik

/*
* JBoss, Home of Professional Open Source
* Copyright 2009, Red Hat, Inc. and/or its affiliates, and individual contributors
* by the @authors tag. See the copyright.txt in the distribution for a
* full listing of individual contributors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
* http://www.apache.org/licenses/LICENSE-2.0

hferentschik

Moving along the road to a Hibernate Validator 4.3 release I am happy to announce the release of Hibernate Validator 4.3.0.Beta1.

One of our foci this time around was to address existing caching issues. HV-479 addresses the problem that the constraint metadata for a given class would be cached in the so called BeanMetaDataManager without a appropriate eviction policy. In most cases this should not be a problem, but for long running applications with for example hot redeploys it could be. We resolved this issue by introducing SoftLimitMRUCache which has an upper bound for the cached metadata.

HV-564 is another caching related issue. Initally ConstraintValidator instances were only cached if they where created by the Hibernate Validator specific _ConstraintValidatorFacto

hferentschik

A question which came up recently a lot was the question about the release plan for Hibernate 
Validator 4.3. It is time for an answer.

I used to say that Validator 4.3 will align with Bean Validation 1.1, incorporating any changes 
required for this specification update. Work on BV 1.1 is still in full swing and it is still time
to raise your voice for your long missed validation feature. Check out 
[beanvalidation.org=>http://beanvalidation.org/] for information.

Back to Hibernate Validator though. Over the last few months we incorporated a bunch of useful
changes and bug fixes into the code base. For example all string based *ConstraintValidator*s 

hferentschik

		return attributeBindingContainer.makeBagAttributeBinding( attribute,
																  pluralAttributeElementNature( attributeSource ),
																  pluralAttributeKeyBinding( attributeBindingContainer,
																							 attributeSource ),
																  propertyAccessorName( attributeSource ),
																  attributeSource.isIncludedInOptimisticLocking(),
																  false,
																  createMetaAttributeContext( attributeBindingContainer,
																							  attributeSource ) );

hferentschik

@Entity
@Indexed
public class Foo {

        @Id
	public Long id;

        @Field
	public String name;

hferentschik

[color]
        ui = auto
        
[color "branch"]
       current = black reverse
       local = black
       remote = green
        

hferentschik

	@Test
	public void testWithClassBridge() {
		EntityManagerFactory factory = new HibernatePersistence().createEntityManagerFactory( new HashMap() );
		factory.close();
		testScenario( true, 2, false );
	}