September 2009 - hibernate-issues

[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, 8 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, 8 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, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4060) Dates being converted to Timestamps confuse CollectionUpdateAction/PersistentSet

by Phillip Henry (JIRA)

Dates being converted to Timestamps confuse CollectionUpdateAction/PersistentSet -------------------------------------------------------------------------------- Key: HHH-4060 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4060 Project: Hibernate Core Issue Type: Bug Components: core Environment: Hibernate Trunk, all databases Reporter: Phillip Henry Attachments: timestamp_date_bug.zip If an object that has a Set of java.util.Dates is persisted then retrieved, these element become java.sql.Timestamps. This is fine but PersistentSet then treats Sets of Dates and Timetstamps inconsistently. Eg, if the collection is cleared, this results in CollectionUpdateAction thinking the elements need to be deleted from the DB (see how PersistentSet.getDeletes uses Set.contains() when comparing Dates and Timestamps - leading to a call to Timestamp.equals which Date fails). But if the java.util.Date elements (the same that we started with) are then re-added, CollectionUpdateAction thinks that they are the same as the ones the Set once contained (see how PersistentSet.needsInserting compares the re-added elements with its snapshot - leading to a call to Date.equals which Timestamp passes) and therefore does not think it needs to persist them. The result is that no date elements at all are left in the DB by the time the transaction commits. I've attached a test that demonstrates the problem. -- 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, 8 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-372) ClassBridges are not handled in projection

by Thomas Goetz (JIRA)

ClassBridges are not handled in projection ------------------------------------------ Key: HSEARCH-372 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.1.0.GA Reporter: Thomas Goetz Priority: Critical Values that were stored by a ClassBridge are not accessible via projection. Luke shows the values, so I'm sure they are there. I think Emmanuel is already aware of the problem, as stated here: https://forum.hibernate.org/viewtopic.php?f=9&t=996373&view=previous As I run Hibernate Search from within JBoss I'm not quit sure how to demonstrate this bug in a standalone testcase. If someone gave me a hint on how this could be done without too much pain, I'd supply a test case. I use the following annotation on the class to be indexed: @ClassBridge( name = "amount_of_students", index = Index.UN_TOKENIZED, store = Store.YES, impl = StudentsSizeBridge.class) public class Teacher implements Serializable { ... } As I said, the amount_of_students value is correctly stored in the Lucene index (viewable with Luke), but if I try to project the value within a FullTextQuery it is always empty. -- 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, 8 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-382) Indexing fails silently in case the file based index is mounted read only

by Hardy Ferentschik (JIRA)

Indexing fails silently in case the file based index is mounted read only ------------------------------------------------------------------------- Key: HSEARCH-382 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-382 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.1.GA Reporter: Hardy Ferentschik Fix For: 3.2.0 I haven't confirmed this yet, but we should investigate this - https://forum.hibernate.org/viewtopic.php?f=9&t=997789 -- 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, 8 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3841) Add support for lock timeouts

by Christian Daszenies (JIRA)

Add support for lock timeouts ------------------------------ Key: HHH-3841 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3841 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Christian Daszenies It would be nice to support (pessimistic) lock timeouts, as with Oracle's SELECT ... FOR UPDATE WAIT [seconds] syntax. There has been an issue in Project hibernate2 (HB-950) with the same request. -- 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, 8 months

3
4
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, 8 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, 8 months

6
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3968) Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323]

by Jonathan Mastin (JIRA)

Error in SchemaUpdate using HSQLDialect with BigInteger or BigDecimal primary keys [similar to HHH.3323] -------------------------------------------------------------------------------------------------------- Key: HHH-3968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3968 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: HSQLDB: 1.8.0.9 Reporter: Jonathan Mastin Problem --------------- When using HSQLDialect, the following code fails during schema creation: @Entity public class Test { @Id @GeneratedValue(strategy = GenerationType.AUTO) private BigInteger id; } Log output: ---------------- ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Unsuccessful: create table Test (id numeric generated by default as identity (start with 1), primary key (id)) ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Wrong data type: id in statement [create table Test (id numeric generated by default as identity (start with 1)] Expected --------------------------------- The column type is being set as "numeric", but it needs to be set as "integer" or "bigint" for HSQL to be able to parse. >From the HSQL manual: "The supported form is(<colname> INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH n, [INCREMENT BY m])PRIMARY KEY, ...). Support has also been added for BIGINT identity columns. As a result, an IDENTITY column is simply an INTEGER or BIGINT column ..." -- 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, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2009