October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5693) Re-enable entitymanager tests

by Hardy Ferentschik (JIRA)

Re-enable entitymanager tests ----------------------------- Key: HHH-5693 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5693 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.6.0 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.0.0.Alpha1 entitymanager tests were disabled during the move to gradle. The build and tests need to be updated. -- 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, 8 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4876) Postgresql @Lob problem

by Radosław Smogura (JIRA)

Postgresql @Lob problem ----------------------- Key: HHH-4876 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4876 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-4 Environment: Reproducable on Windows and Linux with Postgresql 8.4 Reporter: Radosław Smogura The current version of Hibernate (Beta) wrongly reads PgSQL blob values (mapped from @Lob byte[]). In general Hibernate properly creates OID type columns for storing blobs, but when it read blob it reads oid value instead of LOB referenced by oid valu (so as the output i get 6 bytes length table instead of 120kb table) This works fine in previous release 3.3 / 3.2. This was I saw is: previous version uses getBlob(), but 3.5 version uses getBytes() of resultset class. -- 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, 8 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HHH-4992) Version is incremented when an inverse one-to-many collection is dirtied by adding or removing read-only entities

by Gail Badner (JIRA)

Version is incremented when an inverse one-to-many collection is dirtied by adding or removing read-only entities ----------------------------------------------------------------------------------------------------------------- Key: HHH-4992 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4992 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner If a persistent, read-only entity is added to an inverse one-to-many association, and the owning entity is versioned, then, when flushed, the collection is found to be dirty, the owning entity's version is incremented, but the read-only entity is not actually added or removed from collection. This does not happen when the association is non-inverse. This situation should at least be logged. -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5703) EJB3PostLoadEventListener, as created by EventListenerConfigurator, throws NullPointerException.

by Eduardo Born (JIRA)

EJB3PostLoadEventListener, as created by EventListenerConfigurator, throws NullPointerException. ------------------------------------------------------------------------------------------------ Key: HHH-5703 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5703 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.6 Reporter: Eduardo Born EJB3PostLoadEventListener is created by EventListenerConfigurator with its default constructor: listenerConfig.setPostLoadEventListeners( new PostLoadEventListener[] { new EJB3PostLoadEventListener(), new DefaultPostLoadEventListener() } ); The problem is that it has a callbackHandler field called which remains null, and there is no check in the postLoad method before invoking callbackHandler.postLoad( entity );. This causes a NullPointerException to be thrown there in a few situations. The fix is simple. H+In the EJB3PostLoadEventListener's postLoad() method, replace: public void onPostLoad(PostLoadEvent event) { Object entity = event.getEntity(); callbackHandler.postLoad( entity ); } by: public void onPostLoad(PostLoadEvent event) { if (callbackHandler == null) return; Object entity = event.getEntity(); callbackHandler.postLoad( entity ); } This would prevent the NullPointerException to be thrown when there is no callbackHandler. -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5702) Hibernate always registers JACC event listeners regardless of whether that is enabled or not which causes unecessary exceptions to be thrown.

by Eduardo Born (JIRA)

Hibernate always registers JACC event listeners regardless of whether that is enabled or not which causes unecessary exceptions to be thrown. --------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5702 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5702 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.6 Reporter: Eduardo Born Hibernate always registers JACC event listeners regardless of whether JACC has been enabled or not (by defining the property hibernate.jacc.enabled in the configurations). The JACC even listeners cause exceptions to be thrown in several situations when Hibernate is not running as part of a container. The most common exception I've seen so far is the "java.lang.IllegalArgumentException: unknown handler key" Hibernate should only register the JACC listeners when JACC is enabled. The fix seems to be in the EventListenerConfigurator class. A simple check for the hibernate.jacc.enabled property should be done before adding any of the JACC event listeners (JACCPreDeleteEventListener, JACCPreLoadEventListener, JACCPreUpdateEventListener, JACCPreInsertEventListener). I believe a simple check like if ( properties.containsKey( AvailableSettings.JACC_ENABLED ) ) { ... } should be performed before adding them. In my case these listeners cause exceptions like these to be thrown in a few situations: java.lang.IllegalArgumentException: unknown handler key at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:280) at org.hibernate.secure.JACCPermissions$PolicyContextActions$2.getContextSubject(JACCPermissions.java:111) at org.hibernate.secure.JACCPermissions.getContextSubject(JACCPermissions.java:120) at org.hibernate.secure.JACCPermissions.checkPermission(JACCPermissions.java:59) at org.hibernate.secure.JACCPreLoadEventListener.onPreLoad(JACCPreLoadEventListener.java:53) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:149) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:898) ...so I have to manually remove these listeners. -- 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, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5177) auditing a child of a mapped superclass forces auditing on siblings

by Clint Popetz (JIRA)

auditing a child of a mapped superclass forces auditing on siblings ------------------------------------------------------------------- Key: HHH-5177 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5177 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.2 Reporter: Clint Popetz If I have: @MappedSuperclass public class Parent { } @Audited @Entity public class AuditedChild extends Parent { } @Entity public class NonAuditedChild extends Parent { } envers will try to flush audit data for changes to NonAuditedChild. -- 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, 8 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-4646) Inconsistent behavior with Audited and MappedSuperclass annotations

by Hernán Chanfreau (JIRA)

Inconsistent behavior with Audited and MappedSuperclass annotations ------------------------------------------------------------------- Key: HHH-4646 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4646 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0-Beta-2, 3.3.2 Environment: 1) hibernate 3.5 build from trunk (7 nov 09) 2) hibernate-core-3.3.2ga with envers build from branch envers-hibernate3.3 (7 nov 09) Reporter: Hernán Chanfreau Priority: Minor Attachments: mapperSuperclass2TestPatch.txt Suppose B is a subclass of A. The subclass B is @Entity and is not audited. The superclass A is @MappedSuperclass. The differents/inconsistent behaviors are: - If A has @Audited at class level, envers does not generate audit info when saving an instance of B. - If A has @Audited at field/getter level, envers generates audit info when saving an instance of B. You can find the original discussion in envers forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=164340 -- 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, 8 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5699) Integer overflow in setFirstResult() and setMaxResults()

by Kyrill Alyoshin (JIRA)

Integer overflow in setFirstResult() and setMaxResults() -------------------------------------------------------- Key: HHH-5699 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5699 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.4 Environment: Oracle 10g Reporter: Kyrill Alyoshin Priority: Minor It seems there is an integer overflow bug in pagination APIs... It is very easy to reproduce. If setFirstResult() is greater than 0, and setMaxResults(Integer.MAX_VALUE), the query will return no results. But the moment we set maxResults to (Integer.MAX_VALUE - firstResult), everything works as expected. -- 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, 8 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-603) Expose pluggable services as loosely coupled components to DirectoryProvider, manage lifecycle of services started and registered by DirectoryProviders

by Sanne Grinovero (JIRA)

Expose pluggable services as loosely coupled components to DirectoryProvider, manage lifecycle of services started and registered by DirectoryProviders ------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HSEARCH-603 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-603 Project: Hibernate Search Issue Type: New Feature Components: directory provider, integration Reporter: Sanne Grinovero Fix For: 3.3.0.Beta2 As designed on the mailing list: http://lists.jboss.org/pipermail/hibernate-dev/2010-October/005572.html -- 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, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-617) Move monitoring section as a top level chapter.

by Emmanuel Bernard (JIRA)

Move monitoring section as a top level chapter. ----------------------------------------------- Key: HSEARCH-617 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-617 Project: Hibernate Search Issue Type: Task Components: documentation Affects Versions: 3.3.0.Beta2 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.3.0.Beta3 -- 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, 8 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010