[Hibernate-JIRA] Created: (HHH-7089) NPE during SessionFactoryImpl init when 2L caching is enabled and @NaturalIdCache is used with EHcache
by Eric Dalquist (JIRA)
NPE during SessionFactoryImpl init when 2L caching is enabled and @NaturalIdCache is used with EHcache
------------------------------------------------------------------------------------------------------
Key: HHH-7089
URL: https://hibernate.onjira.com/browse/HHH-7089
Project: Hibernate ORM
Issue Type: Bug
Affects Versions: 4.1.0
Reporter: Eric Dalquist
The org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory always returns null for buildNaturalIdRegion due to an oversight during work on HHH-6974
The result is that if Second-Level caching is enabled and any entity is annotated with @NaturalIdCache session factory creation fails with a NPE
{noformat}
[java] Caused by: java.lang.NullPointerException
[java] at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:361)
[java] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1740)
[java] at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:88)
[java] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
[java] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:889)
[java] at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-7085) Entities marked as @Immutable that have a @NaturalId fail to be inserted with NPE
by Eric Dalquist (JIRA)
Entities marked as @Immutable that have a @NaturalId fail to be inserted with NPE
---------------------------------------------------------------------------------
Key: HHH-7085
URL: https://hibernate.onjira.com/browse/HHH-7085
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.0
Reporter: Eric Dalquist
Due to the work done for HHH-6974 inserting an @Immutable entity with a @NaturalId results in a NullPointerException
The cause appears to be due to read-only entities not having EntityEntry.getLoadedState() populated upon insert and StatefulPersistenceContext.getNaturalIdValues assumes that array will not be null.
{noformat}
Caused by: java.lang.NullPointerException
at org.hibernate.engine.internal.StatefulPersistenceContext.getNaturalIdValues(StatefulPersistenceContext.java:1755)
at org.hibernate.engine.internal.StatefulPersistenceContext.loadedStateInsertedNotification(StatefulPersistenceContext.java:1715)
at org.hibernate.engine.spi.EntityEntry.notifyLoadedStateInserted(EntityEntry.java:390)
at org.hibernate.engine.spi.EntityEntry.postInsert(EntityEntry.java:266)
at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:95)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73)
... 54 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HHH-7023) Deprecate HQL-specific (JDBC-style) positional parameters
by Steve Ebersole (JIRA)
Deprecate HQL-specific (JDBC-style) positional parameters
---------------------------------------------------------
Key: HHH-7023
URL: https://hibernate.onjira.com/browse/HHH-7023
Project: Hibernate ORM
Issue Type: Deprecation
Components: query-hql
Reporter: Steve Ebersole
Deprecate the Hibernate-specific (JDBC-style) positional parameters in favor of the JPA-style.
{code}
// HQL positional parameters:
Query q = session.createQuery( "from Cat c where c.name = ?" )
.setParameter( 1, "Tabitha" )
...
// JPQL style:
Query q = em.createQuery( "from Cat c where c.name = ?1" )
.setParameter( 1, "Tabitha" )
...
JPQL style, from Hibernate API:
Query q = em.createQuery( "from Cat c where c.name = ?1" )
.setParameter( "1", "Tabitha" )
...
{code}
This would allow the following from HQL:
{code}
Query q = session.createQuery( "from Cat c where c.name = ?1" )
.setParameter( 1, "Tabitha" )
...
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HV-550) fail-fast doesn't work on composite constraints
by Emerson Farrugia (JIRA)
fail-fast doesn't work on composite constraints
-----------------------------------------------
Key: HV-550
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-550
Project: Hibernate Validator
Issue Type: Bug
Affects Versions: 4.2.0.Final
Reporter: Emerson Farrugia
I have a composite constraint @Foo that's validated by FooValidator. @Foo's marked with @Bar, which is validated by BarValidator.
When I validate a bean whose property is marked as @Foo, and BarValidator fails, FooValidator is still being run. This prevents me from assuming that BarValidator has passed, which defeats the purpose of marking @Foo with @Bar because FooValidator now has to repeat the work of BarValidator.
The culprit as best I can tell is line 133 of ConstraintTree, which doesn't check the fail-fast property before running the validator of the constraint itself.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months