April 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (METAGEN-58) Subsequent processing rounds are trying to reprocess Entities that are already processed, this causes an error.

by Viet Trinh (JIRA)

Subsequent processing rounds are trying to reprocess Entities that are already processed, this causes an error. --------------------------------------------------------------------------------------------------------------- Key: METAGEN-58 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-58 Project: Hibernate Metamodel Generator Issue Type: Bug Components: processor Affects Versions: 1.1.1.Final Environment: jdk1.6.0_23, Eclipse 3.6, Maven 2, Hibernate version 3.6.1.Final, MS SQL 2005. Reporter: Viet Trinh Assignee: Hardy Ferentschik Priority: Minor I have an entity named "Car" and another processor that creates another entity name "CarAudit". After the first round, the class "Car_" and class "CarAudit" are created, therefore causing a subsequent round of processing since "CarAudit" is marked with @Entity. However, the second round fails with the following error: "diagnostic error: Problem with Filer: Attempt to recreate a file for type com.example.Car_" This is due to not clearing the "metaEntities" list from the context object after every round. Each processing round will use the same processor and context object and try to create all of the meta entries listed in the context during each round. My proposed solution is to clear the metaEntities list from the context object after each round of processing. Sorry, I do not have a test case for this right now. -- 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, 2 months

2
4
0 / 0

[Hibernate-JIRA] Created: (METAGEN-50) Suppress Warnings

by Stephan Bublava (JIRA)

Suppress Warnings ----------------- Key: METAGEN-50 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-50 Project: Hibernate Metamodel Generator Issue Type: Improvement Components: processor Affects Versions: 1.1.1.Final Reporter: Stephan Bublava Assignee: Hardy Ferentschik Priority: Minor Please consider adding a @SuppressWarnings("all") annotation to the generated classes. Warnings in generated code are not helpful. In my case the warnings (driven by IDE settings) are caused by: 1) Entities marked as @Deprecated. 2) A custom Hibernate user type that maps a numeric SQL type into an EnumSet<T>. The generated SingularAttribute does not preserve the type of the set. -- 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, 2 months

3
6
0 / 0

[Hibernate-JIRA] Created: (METAGEN-56) Missing Singular attribute in import when merging attributes

by Martijn Blankestijn (JIRA)

Missing Singular attribute in import when merging attributes ------------------------------------------------------------ Key: METAGEN-56 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-56 Project: Hibernate Metamodel Generator Issue Type: Bug Components: processor Affects Versions: 1.1.1.Final Environment: maven 3.0.2 Java: java version "1.6.0_22", Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Uname: Linux xxx 2.6.32-28-generic-pae #55-Ubuntu SMP Mon Jan 10 22:34:08 UTC 2011 i686 GNU/Linux Reporter: Martijn Blankestijn Assignee: Hardy Ferentschik Attachments: 0001-Missing-SingularAttribute-import-with-mixed-xml-and-.patch, surefire-reports.tar.gz I have failing testcases due to a missing import in the Generated ZeroCoordinates_.java. My analysis: The import "import javax.persistence.metamodel.SingularAttribute;" is not added to the file ZeroCoordinates_.java and will not compile due to this missing dependency. It is a mixed configuration: so in the class JPAMetaModelEntityProcessor (line 237) the call is made to metaEntity.mergeInMembers( alreadyExistingMetaEntity.getMembers() ); This basically means that the attributes of the already existing XML MetaEntity are placed in the attributesMap of the AnnotationMetaEntity. public void mergeInMembers(Collection<MetaAttribute> attributes) { for ( MetaAttribute attribute : attributes ) { members.put( attribute.getPropertyName(), attribute ); } } This means that the AnnotationEmbeddable has a Context, but the members (the merged in Xml-attributes) have a different context. (Do not understand why there are two contexts, can you enlighten me?) In the ClassWriter line 107 for ( MetaAttribute metaMember : members ) { pw.println( " " + metaMember.getDeclarationString() ); } the declaration string is printed. As the attributes are XMLMetaAttribute, their implementation of the getDeclarationString is return "public static volatile " + hostingEntity.importType( getMetaType() ) + "<" + hostingEntity.importType( hostingEntity.getQualifiedName() ) + ", " + hostingEntity.importType( getTypeDeclaration() ) + "> " + getPropertyName() + ";"; The hosting entity of the attribute is still the XmlMetaEmbeddable and when the importType is added, it is added to the wrong context (the context of the XMLMetaEmbeddable and NOT the AnnotationMetaEmbeddable). Possible solution is to change the parent or create a new merged attribute (not ugly like I do below ;-)) MetaAttribute mergedAttribute = new XmlMetaSingleAttribute(this, attribute.getPropertyName(), attribute.getMetaType()); members.put( attribute.getPropertyName(), mergedAttribute ); This resolves the problem with the missing import, but if it is better to have a single context for both annotation and xml elements this might be a cleaner solution. Attached is the 'ugly' solution, but this leaves two failing testcases: testAccessTypeForXmlConfiguredEmbeddables(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) testMixedConfiguration(org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest) The testMixedConfiguration could be a problem that the supplied solution is not yet the definitive answer ;-(: ======================================================= Types do not match: Wrong meta model type expected:<class org.hibernate.jpamodelgen.test.mixedmode.RentalCompany> but was:<interface javax.persistence.metamodel.SingularAttribute> org.testng.Assert.fail(Assert.java:84) at org.testng.Assert.failNotEquals(Assert.java:438) at org.testng.Assert.assertEquals(Assert.java:108) at org.hibernate.jpamodelgen.test.util.TestUtil.assertAttributeTypeInMetaModelFor(TestUtil.java:176) at org.hibernate.jpamodelgen.test.mixedmode.MixedConfigurationTest.testMixedConfiguration(MixedConfigurationTest.java:68) 30 lines not shown ======================================================= The testAccessTypeForXmlConfiguredEmbbedables seems unreleated: assertAbsenceOfFieldInMetamodelFor( ZeroCoordinates.class, "longitude", "Field access should be used, but ZeroCoordinates does not define fields" ); assertAbsenceOfFieldInMetamodelFor( ZeroCoordinates.class, "latitude", "Field access should be used, but ZeroCoordinates does not define fields" ); as I am not completely sure that the asserts are correct. The access type of embeddables dependends on the enclosing entity, so ain't it true that the field AND properties should be generated? Regards, Martijn -- 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, 2 months

2
5
0 / 0

[Hibernate-JIRA] Created: (METAGEN-59) no Meatadata is created for MappedSuperclasses in other directories

by Martin Trummer (JIRA)

no Meatadata is created for MappedSuperclasses in other directories ------------------------------------------------------------------- Key: METAGEN-59 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-59 Project: Hibernate Metamodel Generator Issue Type: Bug Components: processor Affects Versions: 1.1.0.Final Environment: Hibernate 3.5.6 Reporter: Martin Trummer Assignee: Hardy Ferentschik Attachments: pom.xml my entites are in package A (directory src/main/java) and extend base-entities which are also in package A (but in src/generated/java) no metadata is produced for the base-entities if i move the base-entities to the src/main/java (to the same dir where the entities are), everything is working as expected. attached is the relevant part of the maven pom.xml file -- 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, 2 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5659) Problem using Hibernate3.6.0.Final with CLOB field in Oracle.

by Samuel Rettore (JIRA)

Problem using Hibernate3.6.0.Final with CLOB field in Oracle. ------------------------------------------------------------- Key: HHH-5659 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5659 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0 Environment: Hibernate 3.6.0.Final, Database Oracle10G on Linux X64, and JPA Reporter: Samuel Rettore Priority: Minor When migrating my project that works well with Hibernate 3.5.6 End-to 3.6.0.Final the Clob field displays the following error |java.lang.ClassCastException: $Proxy1119 cannot be cast to oracle.sql.CLOB at oracle.jdbc.driver.OraclePreparedStatement.setClob(OraclePreparedStatement.java:7021) at org.hibernate.type.descriptor.sql.ClobTypeDescriptor$1.doBind(ClobTypeDescriptor.java:60) at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:89) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:282) at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277) at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:85) at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2166) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2412) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2856) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:795) at com.sun.enterprise.container.common.impl.EntityManagerWrapper.flush(EntityManagerWrapper.java:407) --- This error appears only with CLOB field. to get more information at their disposal. Thanks Rettore. -- 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, 2 months

13
44
0 / 0

[Hibernate-JIRA] Created: (HHH-5862) ClassCastException overriding with a new Set a existing collection.

by Francisco Philip (JIRA)

ClassCastException overriding with a new Set a existing collection. ------------------------------------------------------------------- Key: HHH-5862 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5862 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0 Environment: testcase, java6, windows Reporter: Francisco Philip Any idea? java.lang.ClassCastException: java.util.HashSet cannot be cast to org.hibernate.collection.PersistentCollection at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:57) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:122) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:83) -- 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, 2 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2896) unified approach for id and natural-id loading

by Steve Ebersole (JIRA)

unified approach for id and natural-id loading ----------------------------------------------- Key: HHH-2896 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2896 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole A follow-on to HHH-2879 in regards to unifying the loading of entities by pk or natural-id. -- 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, 2 months

3
21
0 / 0

[Hibernate-JIRA] Created: (HHH-5275) Criteria.setLockMode does not work correctly

by Björn Moritz (JIRA)

Criteria.setLockMode does not work correctly -------------------------------------------- Key: HHH-5275 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2, Oracle 10 (using org.hibernate.dialect.Oracle10gDialect Reporter: Björn Moritz Priority: Minor Attachments: TestCase.zip The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for determining a possible addition to the SQL statement if using pessimistic locking. This behaviour is different from Hibernate 3.1.3. In the supplied TestCase two threads are reading the same database record; one of those threads should use pessimistic locking thereby blocking the other thread. But both threads can read the database record causing the test to fail. -- 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, 2 months

8
43
0 / 0

[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()

by S.Schnabl (JIRA)

(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush() -------------------------------------------------------------------------------------------------------- Key: HHH-2763 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5, 3.2.4.sp1 Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3 Reporter: S.Schnabl Priority: Critical Attachments: Testcase.zip For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java. [Summarized] It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error: org.hibernate.AssertionFailure: collection [n-side] was not processed by flush() [Explanation] I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity. [Testcase] Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush: Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush() at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205) at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515) ... 29 more Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA. We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes. Seems for me like a serious bug. Need this fixed 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

14 years, 2 months

32
59
0 / 0

[Hibernate-JIRA] Created: (HHH-4439) In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing.

by Eugene Goroschenya (JIRA)

In general it is impossible to override properties defined in @MappedSuperclass to change how they will be handled during auditing. ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-4439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4439 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0.Beta-1, 3.3.2, 3.2.x, 3.5 Reporter: Eugene Goroschenya Priority: Critical It seems there are several use cases with this issue but most important for me is @MappedSuperclass class A { @Audited private String value; } @Entity @Audited class MyAutided extends A { } @Entity class MyNotAutided extends A { } I need MyNotAutided is not audited at all (there is not MyNotAutided_AUD table and MyNotAutided revisions are not created) nut seems it is impossible because use case above leads to creating MyNotAutided_AUD table and creating of revisions for MyNotAutided. I assume @AuditOverride must support it to say that MyNotAutided.value is not audited but it doesn't work. -- 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, 2 months

4
4
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 2011