March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level

by Don Smith (JIRA)

org.hibernate.event.def.DefaultLoadEventListener logs exception at info level ----------------------------------------------------------------------------- Key: HHH-2085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18 Reporter: Don Smith Priority: Minor Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution. Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener: catch(HibernateException e) { log.info("Error performing load command", e); throw e; } -- 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

12 years, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5964) IllegalArgumentException (Parameter value ... was not matching type ...) for JPA-Query: Worked with 3.3.1.GA

by Sebastian Hasait (JIRA)

IllegalArgumentException (Parameter value ... was not matching type ...) for JPA-Query: Worked with 3.3.1.GA ------------------------------------------------------------------------------------------------------------ Key: HHH-5964 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5964 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.1 Reporter: Sebastian Hasait We have switched from core-3.3.1.GA and entity-manager-3.4.0.GA to 3.6.1.Final. Now some queries stopped working. This is caused by an additional type check in org.hibernate.ejb.AbstractQueryImpl#registerParameterBinding@359 which does not care about hibernate-proxies. This method is called from QueryImpl#setParameter(...). This call doesn't exist in 3.4.0.GA. I think the proxies should be as transparent as possible. So if I get a proxy from some relation getter and put this into a query as parameter, there should be no exception. Because the proxy cannot know the concrete type without initializing the proxy-target (reading discriminator from database) there remain four solutions: 1.) Hibernate is not checking the type for proxies OR only ensures expected type and proxy-type are related. 2.) Hibernate initializes the parameter and the type checking works without exception. 3.) Our DAO initializes the parameter before passing. 4.) We rewrite our queries to pass only the PK I would prefer 1 or 2. :-) Will attach test case asap. -- 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

12 years, 9 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5858) Cannot load entities with Clob or Lob properties into stateless sessions

by James Roper (JIRA)

Cannot load entities with Clob or Lob properties into stateless sessions ------------------------------------------------------------------------ Key: HHH-5858 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5858 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Reporter: James Roper I have a an entity with a Clob property: {code:java} @Lob private Clob clobProperty; {code} When I try and load it in a stateless session, I get: {noformat} Exception in thread "main" java.lang.ClassCastException: org.hibernate.impl.StatelessSessionImpl cannot be cast to org.hibernate.engine.jdbc.LobCreationContext at org.hibernate.Hibernate.getLobCreator(Hibernate.java:420) at org.hibernate.type.ClobType.nullSafeGet(ClobType.java:114) at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105) at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2267) at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1423) at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1351) at org.hibernate.loader.Loader.getRow(Loader.java:1251) at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:619) at org.hibernate.loader.Loader.loadSingleRow(Loader.java:307) at org.hibernate.impl.ScrollableResultsImpl.prepareCurrentRow(ScrollableResultsImpl.java:254) at org.hibernate.impl.ScrollableResultsImpl.next(ScrollableResultsImpl.java:123) {noformat} If Lobs in stateless sessions isn't supported, then at very least an error message to that effect should be thrown and the docs should be updated to reflect this, but I don't see why that should be the case, especially considering that both Lobs and stateless session both serve very similar purposes, they are for use when dealing with large datasets that may not fit in memory, and so could well be used together. -- 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

12 years, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4808) SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction)

by Martin Renner (JIRA)

SessionImpl.initializeCollection() does not release JDBC connection (if outside of a transaction) ------------------------------------------------------------------------------------------------- Key: HHH-4808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4808 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2, 3.2.7 Reporter: Martin Renner Priority: Critical With {{ConnectionReleaseMode.AFTER_TRANSACTION}} (the default), Hibernate does not release the JDBC connection when resolving a lazily loaded collection, if this happens *outside* of an active transaction. First, I will describe, what happens if Hibernate executes a query outside of a transaction. Then I will describe how lazy collection loading behaves differently. When the method {{list}} of a query ({{QueryImpl.java}}) is getting called, Hibernate delegates to {{SessionImpl.list()}}. After having loaded the list, {{SessionImpl.list()}} calls {{SessionImpl.afterOperation()}}, which calls {{jdbcContext.afterNontransactionalQuery()}} (as there is no active transaction). This leads to {{ConnectionManager.afterTransaction()}} which releases the JDBC connection. This is exactly what I expect to happen. Now to the lazily loaded collection: {{Hibernate.initialize(collection)}} and {{person.getPets().size()}} both end up in {{SessionImpl.initializeCollection()}}. This call gets dispatched down to {{Loader.doQueryAndInitializeNonLazyCollections()}} and {{Loader.doQuery()}}. The important fact is, that {{ConnectionManager.afterTransaction()}} never gets called (like in the query-example above). The result is, that the JDBC connection is not released. IMHO resolving of a lazily loaded collection should behave like executing a query. {{SessionImpl.initializeCollection()}} should call {{SessionImpl.afterOperation()}} in the same way as {{SessionImpl.list()}} is doing this. I will attach a small demo application which shows the difference (concerning {{ConnectionManager}}) between queries and collections. -- 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

12 years, 9 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5950) Make @UniqueConstraint inheritable

by Manuel Bernhardt (JIRA)

Make @UniqueConstraint inheritable ---------------------------------- Key: HHH-5950 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5950 Project: Hibernate Core Issue Type: New Feature Components: annotations Affects Versions: 3.6.1 Reporter: Manuel Bernhardt It would be really nice to be able to define a @UniquenessConstraint in a @MappedSuperclass so that all subclasses carry this constraint. Right now, the following constraint is ignored: @MappedSuperclass @Table(uniqueConstraints = {@UniqueConstraint(name="inheritedConstraint", columnNames = {"matter", "value"})}) public class Space { ... } -- 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

12 years, 9 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3307) HQL query translation in real SQL ignores the dialect class

by Thomas Schilf (JIRA)

HQL query translation in real SQL ignores the dialect class ----------------------------------------------------------- Key: HHH-3307 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3307 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: dialect file with special JoinFragment and a "transformSelectString" step Reporter: Thomas Schilf We're using a special dialect class for a database. In the dialect is defined a own JoinFragment and a "transformSelectString" step. All workes fine by loading objects over a Criteria class. The generated SQL string is wrong by using named queries (HQL). The SQL string is in normal ANSI-SQL. The SqlGenerator and QueryTranslatorImpl classes from hibernate don't use the dialect 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

12 years, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (EJB-361) Query#setParameter(int position, Object value) wrong implementation

by Fabrice Daugan (JIRA)

Query#setParameter(int position, Object value) wrong implementation ------------------------------------------------------------------- Key: EJB-361 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-361 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Affects Versions: 3.3.2.GA Reporter: Fabrice Daugan The Hibernate JPA javax.persistence.Query#setParameter(int position, Object value) implementation does not suit to the JPA specicafication. Indeed, the actual integer passed to the operation is converted to String by Hibernate and then used to find the named parameter. Please have a look to the folowing stack trace : java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [1] at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:185) at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:240) at org.springframework.orm.jpa.JpaTemplate$9.doInJpa(JpaTemplate.java:316) To repoduce this error : -- 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

12 years, 9 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HV-423) Publish an API change report as part of the documentation

by Hardy Ferentschik (JIRA)

Publish an API change report as part of the documentation --------------------------------------------------------- Key: HV-423 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-423 Project: Hibernate Validator Issue Type: Improvement Components: documentation Affects Versions: 4.2.0.Beta1 Reporter: Hardy Ferentschik Fix For: 4.x These reports can be generated via JDiff or clirr. See also HV-417. -- 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

12 years, 9 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HV-457) Simplify IDE setup of annotation processor by providing a shaded jar

by Kevin Pollet (JIRA)

Simplify IDE setup of annotation processor by providing a shaded jar -------------------------------------------------------------------- Key: HV-457 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-457 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Reporter: Kevin Pollet When configuring the annotation processor in IDEs it's classpath has to be specified. In IDEs like Netbeans or IntelliJ the annotation processor can use the project classpath. But it's better if the classpath of project and annotation processor are isolated. In that case people shall setup manually the annotation processor classpath which has to contain at least HV and BV dependency. As Gunnar said it would be usefull to simplify the annotation processor configuration in IDEs by providing a shaded jar. -- 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

12 years, 9 months

3
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3799) PersistentSet does not honor hashcode/equals contract when loaded eagerly

by Igor Vaynberg (JIRA)

PersistentSet does not honor hashcode/equals contract when loaded eagerly ------------------------------------------------------------------------- Key: HHH-3799 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3799 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Igor Vaynberg Priority: Blocker Attachments: test.zip when persistent set is loaded eagerly in some situations it calls hashcode on its items before their field values are populated and then uses this incorrect hashcode to store them in the set. this makes set items inaccessible by any collection items that rely on hashcode such as contains(), remove(), etc. attached is a simple maven test project that reproduces the error, unzip and mvn test to run the test. -- 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

12 years, 9 months

16
58
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2011