January 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-66) 3.1.0.CR1 incompatible with Hibernate 3.3.0

by Juergen Zimmermann (JIRA)

3.1.0.CR1 incompatible with Hibernate 3.3.0 ------------------------------------------- Key: HV-66 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-66 Project: Hibernate Validator Issue Type: Bug Affects Versions: 3.1.0.CR1 Environment: Hibernate 3.3.0, Hibernate Common Annotations 3.1.0.CR2, Hibernate Annotations 3.4.0.CR2, Hibernate EntityManager 3.4.0.CR2, Javassist, 3.8.1, CGLib 2.2, EHCache 1.5.0, SLF4J 1.5.2, JDK 1.6.0_07 Reporter: Juergen Zimmermann I'm getting this stacktrace after upgrading from Hibernate 3.3.0.CR2 to 3.3.0: java.lang.NoSuchMethodError: org.hibernate.event.PreUpdateEvent.getSource()Lorg/hibernate/engine/SessionImplementor; at org.hibernate.validator.event.ValidateEventListener.onPreUpdate(ValidateEventListener.java:177) at org.hibernate.action.EntityUpdateAction.preUpdate(EntityUpdateAction.java:237) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:88) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:64) at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1141) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:65) at de.hska.kundenverwaltung.db.KundenverwaltungDaoImpl.findKundenByNachname(KundenverwaltungDaoImpl.java:67) at de.hska.kundenverwaltung.KundenverwaltungImpl.updateKunde(KundenverwaltungImpl.java:392) at de.hska.kundenverwaltung.rest.KundenverwaltungResource.updateKunde(KundenverwaltungResource.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jersey.impl.model.method.dispatch.EntityParamDispatchProvider$TypeOutInvoker._dispatch(EntityParamDispatchProvider.java:132) at com.sun.jersey.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:81) at com.sun.jersey.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:133) at com.sun.jersey.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111) at com.sun.jersey.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:71) at com.sun.jersey.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:111) at com.sun.jersey.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:64) at com.sun.jersey.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:680) at com.sun.jersey.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:650) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:309) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at de.hska.util.HskaFilter.doFilter(HskaFilter.java:46) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:857) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509) at java.lang.Thread.run(Thread.java:619) -- 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

14 years, 7 months

8
20
0 / 0

[Hibernate-JIRA] Created: (HHH-2928) optimizers for enhanced id generators should be synchronized against multi-threaded access

by Steve Ebersole (JIRA)

optimizers for enhanced id generators should be synchronized against multi-threaded access ------------------------------------------------------------------------------------------ Key: HHH-2928 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2928 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6 Currently the optimizers do not serialize access to their internal state when applying their optimizations. This only affects the pooled and hilo optimizers. -- 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

14 years, 7 months

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-3739) Problem using BTMTransactionManagerLookup with Tomcat

by Helder Sousa (JIRA)

Problem using BTMTransactionManagerLookup with Tomcat ----------------------------------------------------- Key: HHH-3739 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3739 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 GA Reporter: Helder Sousa Attachments: BTMTransactionManagerLookup.patch Hi. When using Bitronix Transaction Manager with tomcat there is a problem resolving the TransactionManager by JNDI. Please take a look to this thread: http://www.nabble.com/Hibernate-JTATransactionFactory-and-BTMTransactionM... In 5th post, Ludovic wrote: "The UserTransaction name is java:comp/UserTransaction and when a JNDI lookup happens in Tomcat, the Tomcat provider takes precedence because Tomcat registered a java: namespace handler." So, when using BTM in Tomcat, the BTM users should configure in BTM Configuration a JNDI name that does not start with java:comp and the BTMTransactionManagerLookup class should read this configuration: Here is the change to the BTMTransactionManagerLookup class (I attached the patch): public String getUserTransactionName() { try { Class transactionManagerServiceClass = Class.forName("bitronix.tm.TransactionManagerServices"); Method getConfigurationMethod = transactionManagerServiceClass.getMethod("getConfiguration", null); Object configurationInstance = getConfigurationMethod.invoke(null, null); Class bitronixConfigurationClass = configurationInstance.getClass(); Method getJndiUserTransactionNameMethod = bitronixConfigurationClass .getMethod("getJndiUserTransactionName", null); String configuredJndiUserTransactionName = (String) getJndiUserTransactionNameMethod.invoke( configurationInstance, null); if (configuredJndiUserTransactionName != null && configuredJndiUserTransactionName.trim().length() >= 0) { return configuredJndiUserTransactionName; } return "java:comp/UserTransaction"; } catch (Exception e) { throw new HibernateException("Could not obtain BTM UserTransactionName", e); } } Can you apply the patch? Best regards, Helder Sousa -- 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

14 years, 7 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-87) Avoid to trigger optimization during intermediate batches

by Emmanuel Bernard (JIRA)

Avoid to trigger optimization during intermediate batches --------------------------------------------------------- Key: HSEARCH-87 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-87 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard A queue can be batched (esp session.index()) optimization should be delayed for the end of the transaction -- 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

14 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3125) BigDecimal support for id generator from DB sequence

by Tomas Rada (JIRA)

BigDecimal support for id generator from DB sequence ---------------------------------------------------- Key: HHH-3125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3125 Project: Hibernate3 Issue Type: New Feature Environment: Hibernate 3.2, Oracle 10 Reporter: Tomas Rada Currently with using BigDecimal as entity id is thrown exception " this id generator generates long, integer, short or string" - class "IdentifierGeneratorFactory". Is there possibility to add BigDecimal support for id generator? -- 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

14 years, 7 months

6
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2975) Interceptor onFlushDirty collections - previous and current state the same instance

by Clayton J. Kovar (JIRA)

Interceptor onFlushDirty collections - previous and current state the same instance ----------------------------------------------------------------------------------- Key: HHH-2975 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2975 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 - Oracle thin driver 10.1.0.4.0 Reporter: Clayton J. Kovar When calling Session.merge(entity) {therefore the previous state is available} the interceptor's onFlushDirty is called and the previous state for all of the simple properties correctly passes the previous values but with a collection the same collection instance is passed in both the previous and current state arrays. So far I have only seen this behavior on a Map with a one-to-many relationship to another entity. I have not tried it yet with Lists, Sets, or Bags. I'm assuming this is not expected behavior, but please let me know if it is. Best 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

14 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2862) Collection is not associated with any session exception when doing an eager fetch on a non-unique collection.

by Paul Andrews (JIRA)

Collection is not associated with any session exception when doing an eager fetch on a non-unique collection. ------------------------------------------------------------------------------------------------------------- Key: HHH-2862 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2862 Project: Hibernate3 Issue Type: Bug Environment: Hibernate 3.1.3 - Hibernate 3.2.5, HSQLDB, Java5 Reporter: Paul Andrews It is basically caused by having an eager collection where the key of the collection is not unique in the results. The code works as follows in CollectionType.getCollection(): .... persistenceContext.addUninitializedCollection( persister, collection, key ); // some collections are not lazy: if ( initializeImmediately( entityMode ) ) { session.initializeCollection( collection, false ); } else if ( !persister.isLazy() ) { persistenceContext.addNonLazyCollection( collection ); } if ( hasHolder( entityMode ) ) { session.getPersistenceContext().addCollectionHolder( collection ); } if persistenceContext.addUninitializedCollection() detects that the collection with the given key has already been added it clears the session on the old instance of the collection (sets it to null). However, that collection has already been added to the persistence context by an earlier call to this method. So later when StatefulPersistenceContext.initializeNonLazyCollections() is called it iterates through all of the collections in the persistence context (including those which have had their session set to null by addUninitializedCollection()), calling forceInitialization() which throws a 'collection is not associated with any session' exception. -- 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

14 years, 7 months

10
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3695) RegionFactory's no-arg constructor does not get invoked

by Paul Cowan (JIRA)

RegionFactory's no-arg constructor does not get invoked ------------------------------------------------------- Key: HHH-3695 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3695 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.3.1 Reporter: Paul Cowan Priority: Trivial RegionFactory's class Javadoc says: * Implementors should define a constructor in one of two forms:<ul> * <li>MyRegionFactoryImpl({@link java.util.Properties})</li> * <li>MyRegionFactoryImpl()</li> * </ul> but SettingsFactory.createRegionFactory only looks for the one that takes a Properties class. This is relatively minor, I don't think 'fixing' this by just correcting the javadoc is really that big a deal but have patches for both ways. -- 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

14 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-1985) NodeTraverser is not SOE-safe

by Sergey Vladimirov (JIRA)

NodeTraverser is not SOE-safe ----------------------------- Key: HHH-1985 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1985 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.cr3 Reporter: Sergey Vladimirov Priority: Minor org.hibernate.hql.ast.util.NodeTraverser It is possible for java.lang.StackOverflowError to occur in NodeTraverser.java:41;42 with very deep tree. Need another algorith to visit whole tree. 08.08 19:50:09 ERROR [ArpSiteServlet] Servlet.service() for servlet ArpSiteServlet threw exception java.lang.StackOverflowError at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41) at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:41) at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42) at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42) at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42) at org.hibernate.hql.ast.util.NodeTraverser.visitDepthFirst(NodeTraverser.java:42) -- 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

14 years, 7 months

7
9
0 / 0

[Hibernate-JIRA] Created: (HBX-869) SchemaUpdateTask does not actually APPLY the DDL on Mysql 5.0

by Schwark Satyavolu (JIRA)

SchemaUpdateTask does not actually APPLY the DDL on Mysql 5.0 ------------------------------------------------------------- Key: HBX-869 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-869 Project: Hibernate Tools Type: Bug Components: ant Versions: 3.2beta9 Environment: Mysql 5.0, windows Reporter: Schwark Satyavolu Priority: Critical The ant task in verbose mode shows that the table does not exist, prints the ddl for the create table, but in fact does NOT create the table. Yet, the build is reported successful. -- 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

14 years, 7 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2009