July 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5048) @Type ignored by envers?, whole transaction rollbacked, but applcation continues, without warning

by Donovan (JIRA)

@Type ignored by envers?,whole transaction rollbacked, but applcation continues, without warning ------------------------------------------------------------------------------------------------ Key: HHH-5048 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5048 Project: Hibernate Core Issue Type: Bug Components: envers Reporter: Donovan Priority: Blocker Attachments: EuroTypeTest_for_envers.patch Following problem occurs when i audited my entity with a custom type: Testcase included, as a svn-patch on the current envers - trunk. Envers does not use my @Type to save the revision, because it is not a org.hibernate.usertype.UserType, but a extension of org.hibernate.type.DoubleType. This give me a readable exception, i can live with that, but still a bug. Implementing my EuroType as a org.hibernate.usertype.UserType resolves my immediate problem. The worst is that a exception is thrown, transaction is rollbacked, but the exception does not reach my application. As in the testcase, the problem is detected(too late) by query on the entity and you get NULL; Thats why i gave it the prio blocker. Adding @NotAudited on "Euro component" gives you a green test, Envers SHOULD NOT influent this, or at least throw a exception, so i get notified that my entity is not saved or created. -- 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, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-207) Hibernate 3.5.1-Final cannot parse order-by fragment

by Vladimir Kobetic (JIRA)

Hibernate 3.5.1-Final cannot parse order-by fragment ---------------------------------------------------- Key: BVAL-207 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-207 Project: Bean Validation Issue Type: Bug Environment: Hibernate 3.5.1-Final MySQL 5.0 Spring 2.5 Reporter: Vladimir Kobetic Priority: Critical When upgrading from Hibernate 3.2.5.ga to the newest Hibernate 3.5.1-Final with the newest build-with dependent libraries an error occurs during initial phase of launching application. I tried to build and run with all libraries from lib directory from Hibernate zip download. The order-by clause is configured in hbm.xml: <hibernate-mapping> <class name="com.test.Object" table="err"> <id name="id" type="java.lang.Long"> <generator class="native" /> </id> <set name="history" table="history" lazy="true" order-by="timestamp desc" cascade="all-delete-orphan"> <key column="object_id" /> <one-to-many class="com.test.Event" /> </set> </class> </hibernate-mapping> The exception is: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [applicationContext-dao-hibernate.xml]: Invocation of init method failed; nested exception is org.hibernate.HibernateException: Unable to parse order-by fragment Caused by: org.hibernate.HibernateException: Unable to parse order-by fragment at org.hibernate.sql.ordering.antlr.OrderByFragmentTranslator.render(OrderByFragmentTranslator.java:66) at org.hibernate.sql.Template.renderOrderByStringTemplate(Template.java:310) at org.hibernate.persister.collection.AbstractCollectionPersister.<init>(AbstractCollectionPersister.java:557) at org.hibernate.persister.collection.OneToManyPersister.<init>(OneToManyPersister.java:84) at org.hibernate.persister.PersisterFactory.createCollectionPersister(PersisterFactory.java:104) and more... Caused by: java.lang.NullPointerException at org.hibernate.sql.ordering.antlr.OrderByFragmentParser.resolveFunction(OrderByFragmentParser.java:115) at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.expression(GeneratedOrderByFragmentParser.java:619) at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.sortKey(GeneratedOrderByFragmentParser.java:337) at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.sortSpecification(GeneratedOrderByFragmentParser.java:248) at org.hibernate.sql.ordering.antlr.GeneratedOrderByFragmentParser.orderByFragment(GeneratedOrderByFragmentParser.java:192) at org.hibernate.sql.ordering.antlr.OrderByFragmentTranslator.render(OrderByFragmentTranslator.java:60) ... 38 more -- 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, 4 months

7
15
0 / 0

[Hibernate-JIRA] Created: (HHH-5151) Update tutorial section of Hibernate Core to use Annotations

by Emmanuel Bernard (JIRA)

Update tutorial section of Hibernate Core to use Annotations ------------------------------------------------------------ Key: HHH-5151 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5151 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- 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, 4 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-567) mvn release:prepare release:perform fails on branch builds

by Emmanuel Bernard (JIRA)

mvn release:prepare release:perform fails on branch builds ---------------------------------------------------------- Key: HSEARCH-567 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-567 Project: Hibernate Search Issue Type: Bug Reporter: Emmanuel Bernard I tried to release Hibernate 3.2.1 using the release plugin but the plugin failed putting the 3.2.0.final poms in the v_3_2_1 tag. -- 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, 4 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-540) JTA transaction commit causes AssertionFailure: Access a Sealed WorkQueue which has not been sealed

by Tom Waterhouse (JIRA)

JTA transaction commit causes AssertionFailure: Access a Sealed WorkQueue which has not been sealed --------------------------------------------------------------------------------------------------- Key: HSEARCH-540 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-540 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.2.0.Final Environment: Hibernate 3.5.2-Final, Spring 3.0.2.RELEASE, MySQL 5.1.34, Atomikos 3.5.13 Reporter: Tom Waterhouse Attachments: hibernate-search-jta-bug.log When we switched our application to use JTA a number of exceptions are generated on transaction commit. Spring is used by the application; the transactions are managed via the Spring class JtaTransactionManager. The Web app and Hibernate Search worked perfectly using JpaTransactionManager. Exception examples: [2010-06-04 09:04:34.391, 49026]ERROR[http-8080-1](AssertionFailure.java:46) - an assertion failure occured (this may indicate a bug in Hibernate) org.hibernate.annotations.common.AssertionFailure: Access a Sealed WorkQueue which has not been sealed [2010-06-04 09:04:34.395, 49030]ERROR[http-8080-1](AssertionFailure.java:50) - an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.HibernateException: Error while indexing in Hibernate Search (ater transaction completion) The full log file has been attached -- 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, 4 months

5
31
0 / 0

[Hibernate-JIRA] Created: (HHH-5152) Update Configuration section to reflect Hibernate Annotations and Core documentation

by Emmanuel Bernard (JIRA)

Update Configuration section to reflect Hibernate Annotations and Core documentation ------------------------------------------------------------------------------------ Key: HHH-5152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5152 Project: Hibernate Core Issue Type: Sub-task Reporter: Emmanuel Bernard -- 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, 4 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4441) SessionImpl serialization violates java serialization spec

by Paul Ferraro (JIRA)

SessionImpl serialization violates java serialization spec ---------------------------------------------------------- Key: HHH-4441 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4441 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0.Beta-1, 3.3.2 Reporter: Paul Ferraro Attachments: patch.txt The private serialization methods of org.hibernate.impl.SessionImpl must call default[Read|Write]Object() on the object input/output stream before any custom de/serialization logic. According to the Java serialization spec: http://java.sun.com/javase/6/docs/platform/serialization/spec/output.html... "The class's writeObject method, if implemented, is responsible for saving the state of the class. Either ObjectOutputStream's defaultWriteObject or writeFields method must be called once (and only once) before writing any optional data that will be needed by the corresponding readObject method to restore the state of the object; even if no optional data is written, defaultWriteObject or writeFields must still be invoked once. If defaultWriteObject or writeFields is not invoked once prior to the writing of optional data (if any), then the behavior of instance deserialization is undefined in cases where the ObjectInputStream cannot resolve the class which defined the writeObject method in question." http://java.sun.com/javase/6/docs/platform/serialization/spec/input.html#... "The readObject method of the class, if implemented, is responsible for restoring the state of the class. The values of every field of the object whether transient or not, static or not are set to the default value for the fields type. Either ObjectInputStream's defaultReadObject or readFields method must be called once (and only once) before reading any optional data written by the corresponding writeObject method; even if no optional data is read, defaultReadObject or readFields must still be invoked once." One consequence of this spec violation is that you cannot use JBoss Marshalling to serialize a session. For details, see: https://jira.jboss.org/jira/browse/JBMAR-67 Patch attached. -- 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, 4 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4443) Allow generic handling of any Hibernate type for post-insert generated identifiers

by Steve Ebersole (JIRA)

Allow generic handling of any Hibernate type for post-insert generated identifiers ---------------------------------------------------------------------------------- Key: HHH-4443 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4443 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5 See HB-92 for the original request. Much of the discussion unfortunately occurred in a private email thread with the original requester, but here is the proposed solution: Steve Ebersole <steve(a)hibernate.org> wrote: The "more correct" solution is along the lines a contract to allow the type to handle this like you said. I'm thinking something like an optional interface for the type to publish that fact: public interface ResultSetIdentifierConsumer { public Serializable consumeIdentifier(ResultSet resultSet); } then IdentifierGeneratorFactory (called IdentifierGeneratorHelper now btw) can say: public static Serializable get(ResultSet rs, Type type) ... { if ( type instanceof ResultSetIdentifierConsumer ) { return ( ( ResultSetIdentifierConsumer ) type ).consumeIdentifier( rs ); } Class clazz = type.getReturnedClass(); if ( clazz == Long.class ) { return new Long( rs.getLong( 1 ) ); } else if ( clazz == Integer.class ) { return new Integer( rs.getInt( 1 ) ); } else if ( clazz == Short.class ) { return new Short( rs.getShort( 1 ) ); } else if ( clazz == String.class ) { return rs.getString( 1 ); } else { throw ... } } and you can define a type : public class MyCustomLongIdType ... implements ResultSetIdentifierConsumer ... { public Serializable consumeIdentifier(ResultSet resultSet) { return new MyCustomLongId( resultSet.getLong( 1 ) ); } ... } -- 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, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5264) withClause doesn't take into account parent classes

by Douglas Ferguson (JIRA)

withClause doesn't take into account parent classes --------------------------------------------------- Key: HHH-5264 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5264 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.5.1 Reporter: Douglas Ferguson withClause will create and ON clause in the SQL that uses and alias that isn't available, i.e. it is referenced 1 line before it is defined. Consider the following classes A, B, C C is a sub class of B. If I create a criteria on A. Then use critera.createAlias("a.c", "c", LEFT_JOIN, Restrictions.in(c.id, 123)); Then I get the following in my query left outer join C c on ... and b.id = 123 < alias b used before it is defined. left outer join B b on ... -- 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, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop

by Stefan Hauk (JIRA)

ConcurrentModificationException in AbstractBatcher results in infinite loop --------------------------------------------------------------------------- Key: HHH-3006 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3 Environment: Hibernate 3.2.5.ga MySQL 5.0.42 Reporter: Stefan Hauk Priority: Minor Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements() method: Iterator iter = resultSetsToClose.iterator(); while ( iter.hasNext() ) { try { logCloseResults(); ( (ResultSet) iter.next() ).close(); } catch (SQLException e) { // no big deal log.warn("Could not close a JDBC result set", e); } catch (Throwable e) { // sybase driver (jConnect) throwing NPE here in certain cases log.warn("Could not close a JDBC result set", e); } } resultSetsToClose.clear(); In case there is a ConcurrentModificationException thrown when iterating over the resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause. However, the iteration may continue infinitely because of the corrupted HashSet. This pegs one CPU and logs the following stack trace over and over again: 28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not close a JDBC result set java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841) at java.util.HashMap$KeyIterator.next(HashMap.java:877) at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314) at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382) at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324) at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298) at org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492) at com.caucho.util.ThreadPool.run(ThreadPool.java:425) at java.lang.Thread.run(Thread.java:595) The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly. Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching Throwable catches more than that and produces this side-effect. Now I do realize that the ConcurrentModificationException might be caused by not using Hibernate in a correct way, but I haven't determined the cause for it yet. However, I do think that Hibernate should fail more gracefully than it currently does. -- 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, 4 months

14
20
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2010