[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
12 years, 11 months
[Hibernate-JIRA] Created: (METAGEN-63) Parameter for additional entity mapping files is ormXmlList but not ormXml
by Ralph Engelmann (JIRA)
Parameter for additional entity mapping files is ormXmlList but not ormXml
--------------------------------------------------------------------------
Key: METAGEN-63
URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-63
Project: Hibernate Metamodel Generator
Issue Type: Bug
Components: documentation
Affects Versions: 1.1.1.Final
Reporter: Ralph Engelmann
Assignee: Hardy Ferentschik
Priority: Trivial
In the "Hibernate JPA 2 Metamodel Generator - Reference Guide" 1.1.1.Final, the parameter to llows to specify additional entity mapping files is {{orm.xml}}.
{quote}
2.3. Processor specific options
...
|ormXml|Allows to specify additional entity mapping files. The specified value for this option is a comma separated string of mapping file names. Even when this option is specified /META-INF/orm.xml is implicit.|
{quote}
But in the code it is {{ormXmlList}}.
{code:title=JPAMetaModelEntityProcessor line 77}
public static final String ORM_XML_OPTION = "ormXmlList";
{code}
One of them should be changed so that documentation and code match.
--
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, 11 months
[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
12 years, 11 months
[Hibernate-JIRA] Created: (METAGEN-78) Support for Java 7
by Jonathan Russell (JIRA)
Support for Java 7
------------------
Key: METAGEN-78
URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-78
Project: Hibernate Metamodel Generator
Issue Type: Improvement
Components: processor
Affects Versions: 1.1.1.Final, 1.2.next, 2.0
Environment: Hibernate 3.6.4.Final, Metamodel Generator 1.1.1.Final, Java 7
Reporter: Jonathan Russell
Assignee: Hardy Ferentschik
When compiling my JPA2 project using Java 7 I get the following warning:
[INFO] diagnostic Note: Hibernate JPA 2 Static-Metamodel Generator 1.1.1.Final
[INFO] diagnostic warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7'
Looking at the source for the class I see:
@SupportedSourceVersion(RELEASE_6)
...
public class JPAMetaModelEntityProcessor extends AbstractProcessor {
I don't know what kind of problems, if any, actually result at this time. However, I'd like to be able to use the MetaModel and Java 7.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[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
12 years, 11 months