April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3718) call to id getter initializes proxy when using AccessType( "field" )

by Paul Lorenz (JIRA)

call to id getter initializes proxy when using AccessType( "field" ) -------------------------------------------------------------------- Key: HHH-3718 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3718 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: hibernate 3.3.1, hibernate annotations 3.4.0, running on windows, linux and solaris, using sybase 15 Reporter: Paul Lorenz Calling getter for id when using AccessType( "field" ) causes proxy initialization. In org.hibernate.proxy.proxy.pojo.BasicLazyInitializer there is the code else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } However, when using field access, the getIdentifierMethod will be null. I fixed this for us by changing DirectPropertyAccessor by adding a Method attribute to the DirectGetter inner class, and looking up the appropriate getter in the constructor. As far as I can tell, getMethod is only used in two places. In the above case, to the get the identity getter and in PojoComponentTupilizer.isMethodOf. This doesn't seem to break anything. I don't know if this is a clean solution, seems a little hacky to me, however, it would be great if the issue could be fixed somehow. public static final class DirectGetter implements Getter { private final transient Field field; private final Class clazz; private final String name; private Method method; DirectGetter(Field field, Class clazz, String name) { this.field = field; this.clazz = clazz; this.name = name; try { BeanInfo beanInfo = Introspector.getBeanInfo( clazz ); PropertyDescriptor[] pdArray = beanInfo.getPropertyDescriptors(); if ( pdArray != null ) { for (PropertyDescriptor pd : pdArray ) { if ( pd.getName().equals( name ) ) { this.method = pd.getReadMethod(); } } } } catch ( Exception e ) { // ignore } } public Object get(Object target) throws HibernateException { try { return field.get(target); } catch (Exception e) { throw new PropertyAccessException(e, "could not get a field value by reflection", false, clazz, name); } } public Object getForInsert(Object target, Map mergeMap, SessionImplementor session) { return get( target ); } public Method getMethod() { return method; } public String getMethodName() { return method == null ? null : method.getName(); } public Class getReturnType() { return field.getType(); } Object readResolve() { return new DirectGetter( getField(clazz, name), clazz, name ); } public String toString() { return "DirectGetter(" + clazz.getName() + '.' + name + ')'; } } -- 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

13 years, 11 months

10
18
0 / 0

[Hibernate-JIRA] Created: (HHH-7274) Developer Guide reverses discussion of CMTTransactionFactory and JTATransactionFactory

by Steve Ebersole (JIRA)

Developer Guide reverses discussion of CMTTransactionFactory and JTATransactionFactory -------------------------------------------------------------------------------------- Key: HHH-7274 URL: https://hibernate.onjira.com/browse/HHH-7274 Project: Hibernate ORM Issue Type: Bug Components: documentation Reporter: Steve Ebersole Assignee: Steve Ebersole -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7252) EntityManager not retaining LockOptions context when mapping exceptions.

by Bryan Varner (JIRA)

EntityManager not retaining LockOptions context when mapping exceptions. ------------------------------------------------------------------------ Key: HHH-7252 URL: https://hibernate.onjira.com/browse/HHH-7252 Project: Hibernate ORM Issue Type: Bug Components: entity-manager Affects Versions: 4.1.2 Environment: PostgreSQL 9.1 Reporter: Bryan Varner Priority: Critical AbstractEntityManagerImpl.java:791 (Implementation of EntityManager.find()) This line defines a local LockOptions and sets it to null. A conditional execution for including lock options on line 795 evaluates the LockOptions but never sets it back to the local. When an exception occurs (lock timeout, or otherwise) the lockOptions have not been set to anything but null, and incorrect exceptions are resolved and thrown. Specifically, you get PessimisticLockException even when you should get LockTimeoutException. This is marking transactions as rollback only, and causing subsequent code to fail gloriously. Below is the offensive function, notice that lockOptions is never set to anything other than =null. {code} public <A> A find(Class<A> entityClass, Object primaryKey, LockModeType lockModeType, Map<String, Object> properties) { CacheMode previousCacheMode = getSession().getCacheMode(); CacheMode cacheMode = determineAppropriateLocalCacheMode( properties ); LockOptions lockOptions = null; try { getSession().setCacheMode( cacheMode ); if ( lockModeType != null ) { return ( A ) getSession().get( entityClass, ( Serializable ) primaryKey, getLockRequest( lockModeType, properties ) ); } else { return ( A ) getSession().get( entityClass, ( Serializable ) primaryKey ); } } catch ( ObjectDeletedException e ) { //the spec is silent about people doing remove() find() on the same PC return null; } catch ( ObjectNotFoundException e ) { //should not happen on the entity itself with get throw new IllegalArgumentException( e.getMessage(), e ); } catch ( MappingException e ) { throw new IllegalArgumentException( e.getMessage(), e ); } catch ( TypeMismatchException e ) { throw new IllegalArgumentException( e.getMessage(), e ); } catch ( ClassCastException e ) { throw new IllegalArgumentException( e.getMessage(), e ); } catch ( HibernateException he ) { throw convert( he, lockOptions ); } finally { getSession().setCacheMode( previousCacheMode ); } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-7245) Inline natural-id synchronization doesn't consider objects loaded from shared cache

by Guenther Demetz (JIRA)

Inline natural-id synchronization doesn't consider objects loaded from shared cache ----------------------------------------------------------------------------------- Key: HHH-7245 URL: https://hibernate.onjira.com/browse/HHH-7245 Project: Hibernate ORM Issue Type: Bug Components: caching (L2), core Affects Versions: 4.1.2 Reporter: Guenther Demetz Similiar to HHH-7237. Inline natural-id synch process relies on all entity objects in persistence context having it's according natural-id values cached in the NaturalIdResolutionCache. While we assured that most scenarios, we forgot about entity loads from shared cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7279) Prevent identical re-cachings in natural-id shared cache

by Guenther Demetz (JIRA)

Prevent identical re-cachings in natural-id shared cache -------------------------------------------------------- Key: HHH-7279 URL: https://hibernate.onjira.com/browse/HHH-7279 Project: Hibernate ORM Issue Type: Improvement Components: caching (L2) Affects Versions: 4.1.2 Reporter: Guenther Demetz Priority: Minor Prevent re-cachings in natural-id region if according key is already cached. Pull-request will follow. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7278) Natural-id shared cache afterTransactionCompletionProcess does not distinguish between success and failure

by Guenther Demetz (JIRA)

Natural-id shared cache afterTransactionCompletionProcess does not distinguish between success and failure ----------------------------------------------------------------------------------------------------------- Key: HHH-7278 URL: https://hibernate.onjira.com/browse/HHH-7278 Project: Hibernate ORM Issue Type: Bug Components: caching (L2) Affects Versions: 4.1.2 Reporter: Guenther Demetz Natural-id shared cache afterTransactionCompletionProcess does not consider the boolean variable success, so basically it's doing the same operations regardless if the transaction where finally commited or rollbacked. Pullrequest with testcases will follow .. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7265) ConcurrentModificationException in SynchronizationRegistryImpl.notifySynchronizationsAfterTransactionCompletion due to SynchronizationRegistryImpl.clearSynchronizations clearing SynchronizationRegistryImpl.synchronizations

by Scott Marlow (JIRA)

ConcurrentModificationException in SynchronizationRegistryImpl.notifySynchronizationsAfterTransactionCompletion due to SynchronizationRegistryImpl.clearSynchronizations clearing SynchronizationRegistryImpl.synchronizations ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-7265 URL: https://hibernate.onjira.com/browse/HHH-7265 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Environment: AS7 7.1.1 Reporter: Scott Marlow Fix For: 4.1.3 forum post link here includes the AS7 test case and description https://community.jboss.org/thread/197649?start=0&tstart=0 http://pastie.org/3819424 is the call stack showing SynchronizationRegistryImpl.notifySynchronizationsAfterTransactionCompletion looping on synchronization which is cleared mid-loop by SynchronizationRegistryImpl.clearSynchronizations -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

5
14
0 / 0

[Hibernate-JIRA] Created: (HHH-7239) centralize before/after transaction callbacks in TransactionCoordinator

by Shawn Clowater (JIRA)

centralize before/after transaction callbacks in TransactionCoordinator ----------------------------------------------------------------------- Key: HHH-7239 URL: https://hibernate.onjira.com/browse/HHH-7239 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Environment: Hibernate 4.1.2, database n/a Reporter: Shawn Clowater There are 2 issues that came to light during extended testing of the Shared Transaction impl. 1st issue is that when a Session is opened during a shared transaction scenario it registers a TransactionObserver with the TransactionCoordinatorImpl to perform operations such as managedFlush and manageClose calls on the child sessions. This observer is not release until the transaction completes so even if the session is closed it can never be garbage collected. 2nd issue is that the afterTransaction/beforeTransaction processes are registered with the ActionQueue belonging to a Session and when the transaction coordinator completes the transaction it only calls the afterTransactionCompletion on the Session that owns the TransactionCoordinator and not any of the child sessions. Originally suggested that the session remove itself from the observer list on close and that the created observer should also call the before/after transaction methods but an alternative solution was discussed where the TransactionCoordinator and not the ActionQueue would be where the after transaction processes are registered. The ActionQueue would register actions with the Coordinator vs. keeping its own lists. Test cases showing both scenarios to follow shortly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
9
0 / 0

[Hibernate-JIRA] Created: (HHH-7187) envers tests fail on other DBs except the default H2

by Strong Liu (JIRA)

envers tests fail on other DBs except the default H2 ---------------------------------------------------- Key: HHH-7187 URL: https://hibernate.onjira.com/browse/HHH-7187 Project: Hibernate ORM Issue Type: Bug Components: envers Reporter: Strong Liu Fix For: 4.1.2 due to the change of HHH-7185, there are some failing tests: {quote} All Failed Tests Test Name Duration Age >>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testTransactionRollback[0] 0.016 1 >>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testDataNotPersisted[0] 0.084 1 >>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testTransactionRollback[1] 0.01 1 >>> org.hibernate.envers.test.integration.jta.JtaExceptionListener.testDataNotPersisted[1] 0.013 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.initData[0] 0.097 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory1[0] 0.0050 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory2[0] 0.0010 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testRevisionsCounts[0] 0.0020 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.initData[1] 0.115 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory1[1] 0.0010 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testHistory2[1] 0.0010 1 >>> org.hibernate.envers.test.integration.manytomany.unidirectional.M2MIndexedListNotAuditedTarget.testRevisionsCounts[1] 0.0 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId1[0] 0.048 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId2[0] 0.029 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testRevisionsCounts[0] 0.016 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId1[1] 0.041 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testHistoryOfId2[1] 0.025 1 >>> org.hibernate.envers.test.integration.naming.BasicNaming.testRevisionsCounts[1] 0.03 1 >>> org.hibernate.envers.test.integration.naming.EstonianTableAlias.testAuditChildTableAlias[0] 0.033 1 >>> org.hibernate.envers.test.integration.naming.EstonianTableAlias.testAuditChildTableAlias[1] 0.044 1 >>> org.hibernate.envers.test.integration.naming.VersionsJoinTableNaming.testHistoryOfUniId1[0] 0.108 1 >>> org.hibernate.envers.test.integration.naming.VersionsJoinTableNaming.testRevisionsCounts[0] 0.031 1 >>> org.hibernate.envers.test.integration.readwriteexpression.ReadWriteExpressionChange.shouldRespectWriteExpression[0] 0.0030 1 >>> org.hibernate.envers.test.integration.readwriteexpression.ReadWriteExpressionChange.shouldRespectWriteExpression[1] 0.0040 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testDatesForRevisions[0] 0.0090 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testFindRevision[0] 0.0050 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testRevisionsForDates[0] 0.012 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps[0] 0.0030 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps1[0] 0.0040 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testDatesForRevisions[1] 0.0070 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testFindRevision[1] 0.0040 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testRevisionsForDates[1] 0.027 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps[1] 0.014 1 >>> org.hibernate.envers.test.integration.reventity.CustomDate.testTimestamps1[1] 0.015 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.initData[0] 0.0090 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testHistoryOfId1[0] 0.0010 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testRevisionsCounts[0] 0.0 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.initData[1] 0.0060 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testHistoryOfId1[1] 0.0090 1 >>> org.hibernate.envers.test.integration.reventity.DifferentDBSchemaTest.testRevisionsCounts[1] 0.0 1 >>> org.hibernate.envers.test.integration.strategy.ValidityAuditStrategyRevEndTsTest.testAllRevEndTimeStamps[0] 0.145 1 >>> org.hibernate.envers.test.integration.strategy.ValidityAuditStrategyRevEndTsTest.testAllRevEndTimeStamps[1] 0.173 1 {quote} this is caused by the _org.hibernate.envers.test.EnversTestingJtaBootstrap#updateConfigAndCreateTM_, this class updates the db connection url and appends a `;AUTOCOMMIT=OFF`, but this property is only valid on H2 do tests using _org.hibernate.envers.test.EnversTestingJtaBootstrap_ are supposed only running on H2? if so, we need move those tests into _src/test/main_ or we need to fix these tests -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-798) Make use of categories instead of fqcn for logging

by Emmanuel Bernard (JIRA)

Make use of categories instead of fqcn for logging -------------------------------------------------- Key: HSEARCH-798 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-798 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Emmanuel Bernard Fix For: 4.0 http://community.jboss.org/wiki/HowToLogInJBossProjects We need to define the set of categories we wish to have eg: * org.hibernate.search.query * org.hibernate.search.hcore * org.hibernate.search.batchindexing etc The idea behind category is that they are more stable than classes and thus better for the user 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

13 years, 11 months

3
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2012