April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7237) Inline natural-id synchronization doesn't consider reattached objects

by Guenther Demetz (JIRA)

Inline natural-id synchronization doesn't consider reattached objects --------------------------------------------------------------------- Key: HHH-7237 URL: https://hibernate.onjira.com/browse/HHH-7237 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Reporter: Guenther Demetz 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 for the 'persist','update' and 'load from datasource' scenarios, we forgot about reattachements where the object get not load again from datasource, these are: session.update(object) and session.lock(object,LockMode.None). The problem rises when detaching objects and then re-attaching them to a new session. See pull-requests for solution proposal and according testcases. -- 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-7225) NullPointerException after persisting null entity value as natural-Id

by Guenther Demetz (JIRA)

NullPointerException after persisting null entity value as natural-Id --------------------------------------------------------------------- Key: HHH-7225 URL: https://hibernate.onjira.com/browse/HHH-7225 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Reporter: Guenther Demetz Priority: Minor This request is basically a reopening of HHH-7158. story-line: -Fixing of HHH-7158 did successfully solve both attached testmethods, but only the first one was integrated into hibernate matrix tests. -Fixing of HHH-7206 did slightly change the way how natural-id-vales are compared, causing now testmethod2 fail again. before HHH-7206: {code} // lengths have already been verified at this point for ( int i = 0; i < naturalIdTypes.length; i++ ) { if ( ! naturalIdTypes[i].isEqual( naturalIdValues[i], values[i] ) ) { return false; } } {code} after HHH-7206: (please notice now there has appeared *persister.getFactory()* as third parameter) {code} // lengths have already been verified at this point for ( int i = 0; i < naturalIdTypes.length; i++ ) { if ( ! naturalIdTypes[i].isEqual( values[i], otherValues[i], persister.getFactory() ) ) { return false; } } return true; {code} Proposed solutions: Either revert back to using the isEqual method again with 2 parameters only, or alternatevely make method EntityType#isEqual(Object x, Object y, SessionFactoryImplementor factory) stable against null x,y values as proposed in HHH-7158. I don't know which one is the better solution, but both solution make the attached testcases go through without fails. -- 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: (OGM-158) Hibernate OGM is always activated (even when ORM is used) because OgmIntegrator is always called

by Emmanuel Bernard (JIRA)

Hibernate OGM is always activated (even when ORM is used) because OgmIntegrator is always called ------------------------------------------------------------------------------------------------ Key: OGM-158 URL: https://hibernate.onjira.com/browse/OGM-158 Project: Hibernate OGM Issue Type: Bug Components: core Reporter: Emmanuel Bernard -- 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: (HSEARCH-1102) Avoid forceful generation of loggers compatible with older JBoss Logger

by Sanne Grinovero (JIRA)

Avoid forceful generation of loggers compatible with older JBoss Logger ------------------------------------------------------------------------ Key: HSEARCH-1102 URL: https://hibernate.onjira.com/browse/HSEARCH-1102 Project: Hibernate Search Issue Type: Deprecation Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.2 We were using an annotation processor option to make sure the built Hibernate Search would work on JBoss Logger 3.0 (JBoss AS 7.0). Let's move forward (this will still work on AS 7.1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7269) mavenCentral() should be made available as part of buildscript repositories

by Steve Ebersole (JIRA)

mavenCentral() should be made available as part of buildscript repositories --------------------------------------------------------------------------- Key: HHH-7269 URL: https://hibernate.onjira.com/browse/HHH-7269 Project: Hibernate ORM Issue Type: Bug Components: build 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
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-821) Finalize SearchFactory API decisions

by Sanne Grinovero (JIRA)

Finalize SearchFactory API decisions ------------------------------------ Key: HSEARCH-821 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-821 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Priority: Blocker When introducing HSEARCH-750 we created these methods: {code}org.hibernate.search.SearchFactory.openIndexReader(Class<?>...) org.hibernate.search.SearchFactory.closeIndexReader(IndexReader){code} An alternative idea would be to add a single indirection, as for example searchFactory.getReaderProvider().open / close This task is about taking a final decision on that matter, and review the SearchFactory API for other methods as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-495) Many locks on AnnotatedElements

by Loïc DIAS DA SILVA (JIRA)

Many locks on AnnotatedElements ------------------------------- Key: HV-495 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-495 Project: Hibernate Validator Issue Type: Patch Components: validators Affects Versions: 4.2.0.CR1 Environment: GNU/Linux, JVM 6.0, Hibernate Validator 4.2.0.CR1 Reporter: Loïc DIAS DA SILVA Attachments: jmeter-graph.docx, patch-ldds.patch Hi all, we use Hibernate Validator 4.2.0-CR1 (previously Apache BVAL) for one of our API projects. All is working fine for our needs except one big issue recently discovered during JMeter tests. Several injectors make many requests from some Amazon cloud servers to our API and starting from a number of requests the response time begins to increase eavily, making a big jump from about 100ms in average to more than 5s. After investigating we have seen many locks in some AnnotatedElement methods (mainly getAnnotation). I've then made a little patch on hibernate in order to cache this kind of requests as i've not found any other cleaver/yet implemented way.. Since this patch all is working very well for us.. Regards. -- 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
13
0 / 0

[Hibernate-JIRA] Created: (HHH-7268) Unable to lookup JNDI in JBoss 5

by T (JIRA)

Unable to lookup JNDI in JBoss 5 -------------------------------- Key: HHH-7268 URL: https://hibernate.onjira.com/browse/HHH-7268 Project: Hibernate ORM Issue Type: Bug Affects Versions: 4.1.2, 4.1.1 Environment: hibernate 4.1.2.Final, JBoss 5.1.0.GA, Spring 3.1.1 Reporter: T Priority: Minor There seems to be a problem using JNDI in Hibernate 4 in JBoss 5. The hibernate jar files are deployed to WEB-INF\lib folder. I have defined jboss-web.xml and can see the data source is bounded. INFO [org.jboss.resource.connectionmanager.ConnectionFactoryBindingService] (main) Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=jdbc/my_app' to JNDI name 'java:jdbc/my_app' ... However, the following error is received. It doesn't matter if I use java:/jdbc/my_app or not or java:/comp/env/jdbc/my_app. If I switched to use DriverManagerDataSource for Hibernate, my app can deploy without a problem. Caused by: org.hibernate.service.jndi.JndiException: Unable to lookup JNDI name [/jdbc/my_app] at org.hibernate.service.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:68) at org.hibernate.service.jdbc.connections.internal.DatasourceConnectionProviderImpl.configure(DatasourceConnectionProviderImpl.java:116) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.buildJdbcConnectionAccess(JdbcServicesImpl.java:223) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:89) at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71) at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2274) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2270) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1739) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1779) at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFactory(LocalSessionFactoryBuilder.java:189) at org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:350) at org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:335) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452) ... 252 more Caused by: javax.naming.NameNotFoundException: jdbc not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) at org.jnp.server.NamingServer.getObject(NamingServer.java:785) at org.jnp.server.NamingServer.lookup(NamingServer.java:396) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726) at javax.naming.InitialContext.lookup(InitialContext.java:396) at org.hibernate.service.jndi.internal.JndiServiceImpl.locate(JndiServiceImpl.java:65) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7267) Eager loading @OneToMany class with @EmbeddedId and @DiscriminatorColumn fails

by Jan Čustović (JIRA)

Eager loading @OneToMany class with @EmbeddedId and @DiscriminatorColumn fails ------------------------------------------------------------------------------ Key: HHH-7267 URL: https://hibernate.onjira.com/browse/HHH-7267 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2, 3.6.10 Environment: Windows 7 x64 Reporter: Jan Čustović Priority: Critical When I try to load a user which has an owner I get this error. The problem is in @OneToMany userRoles which has @EmbeddedId in combination with @DiscriminatorColumn (if I remove @DiscriminatorColumn it works). Hibernate gets confused because users and users owner userRoles must be loaded. {code:title=Error|borderStyle=solid} 13:00:08.925 [http-bio-8080-exec-1] ERROR org.hibernate.AssertionFailure - HHH000099: an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session): org.hibernate.AssertionFailure: null identifier 13:00:08.951 [http-bio-8080-exec-1] ERROR com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor - null identifier org.hibernate.AssertionFailure: null identifier at org.hibernate.engine.spi.EntityKey.<init>(EntityKey.java:69) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.internal.AbstractSessionImpl.generateEntityKey(AbstractSessionImpl.java:242) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.loader.Loader.extractKeysFromResultSet(Loader.java:722) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:635) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.loader.Loader.doQuery(Loader.java:850) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:289) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259) ~[hibernate-core-4.1.2.Final.jar:4.1.2.Final] ... {code} {code:title=User.java|borderStyle=solid} @Entity @Table(name = "user") @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) public class User extends AbstractBaseEntity { @Id @GeneratedValue @Column(name = "id") private Integer id; @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name = "owner_id", nullable = true) private User owner; @OneToMany(fetch = FetchType.EAGER, mappedBy = "pk.user") private Set<UserRole> userRoles; ... Other fields, getters & setters, hash, equals } {code} {code:title=UserRole.java|borderStyle=solid} @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) @DiscriminatorColumn(name = "type", discriminatorType = DiscriminatorType.STRING) @DiscriminatorValue("DEFAULT") @Table(name = "user_role") public class UserRole implements Serializable { @EmbeddedId private UserRolePK pk; ... Getters & setters, hash, equals } {code} {code:title=UserRolePK.java|borderStyle=solid} @Embeddable public class UserRolePK implements Serializable { @ManyToOne private User user; @ManyToOne private Role role; ... Getters & setters, hash, equals } {code} When I try to change owner to lazy load getOwner() return object with all properties null. {code} ... @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "owner_id", nullable = true) private User owner; ... {code} Changing userRoles to lazy load fixes the problem and everything works good but I need eager load so i added FetchMode.SUBSELECT which also works but I don't want to user hibernate annotations. {code} ... @OneToMany(fetch = FetchType.EAGER, mappedBy = "pk.user") @Fetch(value = FetchMode.SUBSELECT) private Set<UserRole> userRoles; ... {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6790) Add option to SequenceStyleGenerator to prefer a "sequence per entity"

by Steve Ebersole (JIRA)

Add option to SequenceStyleGenerator to prefer a "sequence per entity" ----------------------------------------------------------------------- Key: HHH-6790 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6790 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.0 Basically this is a RFE for a corollary to {{org.hibernate.id.enhanced.TableGenerator#CONFIG_PREFER_SEGMENT_PER_ENTITY}} for the {{org.hibernate.id.enhanced.SequenceStyleGenerator}}. Currently, when no sequence name is given the default name (hibernate_sequence) is used. So this option would force {{org.hibernate.id.enhanced.SequenceStyleGenerator}} to determine a sequence name when none is explicitly given based on the name of the entity. The logic would be very similar to {{org.hibernate.id.enhanced.TableGenerator#determineDefaultSegmentValue}} but leveraging {{org.hibernate.id.IdentifierGenerator#ENTITY_NAME}} instead of {{org.hibernate.id.PersistentIdentifierGenerator#TABLE}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
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