[Hibernate-JIRA] Created: (HHH-3523) org.hibernate.id.enhanced.SequenceStyleGenerator causes org.hibernate.MappingException with SAPDB and DB2Dialect
by Damir Malenicic (JIRA)
org.hibernate.id.enhanced.SequenceStyleGenerator causes org.hibernate.MappingException with SAPDB and DB2Dialect
----------------------------------------------------------------------------------------------------------------
Key: HHH-3523
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3523
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1.GA
Generation of DDL scripts for DB2Dialect and SAPDBDialect
Reporter: Damir Malenicic
Attachments: db2-sapdb-bug.zip
While generating DDL scripts for mapping files that declare id <generator class="org.hibernate.id.enhanced.SequenceStyleGenerator"> the following exception is thrown:
org.hibernate.MappingException: Dialect does not support pooled sequences
at org.hibernate.dialect.Dialect.getCreateSequenceString(Dialect.java:701)
at org.hibernate.dialect.Dialect.getCreateSequenceStrings(Dialect.java:659)
at org.hibernate.id.enhanced.SequenceStructure.sqlCreateStrings(SequenceStructure.java:139)
at org.hibernate.id.enhanced.SequenceStyleGenerator.sqlCreateStrings(SequenceStyleGenerator.java:328)
at org.hibernate.cfg.Configuration.generateSchemaCreationScript(Configuration.java:945)
at org.hibernate.tool.hbm2ddl.SchemaExport.<init>(SchemaExport.java:129)
at org.hibernate.tool.hbm2ddl.SchemaExport.<init>(SchemaExport.java:91)
I suspect the cause is in
org.hibernate.dialect.Dialect#getCreateSequenceString(String sequenceName, int initialValue, int incrementSize)
if ( supportsPooledSequences() ) {
return getCreateSequenceString( sequenceName ) + " start with " + initialValue + " increment by " + incrementSize;
}
throw new MappingException( "Dialect does not support pooled sequences" );
This call requires not just that dialect supports sequences but that dialect supports pooled sequences.
But the algorithm that tries to determine whether the table should be used to emulate the sequence lets the dialects that supports sequences but not pooled sequences to slip through. It looks like the DB2 and SAPDB dialects fail in this category because of:
org.hibernate.id.enhanced.SequenceStyleGenerator#configure(Type type, Properties params, Dialect dialect)
...
if ( dialect.supportsSequences() && !forceTableUse ) {
if ( OptimizerFactory.POOL.equals( optimizationStrategy ) && !dialect.supportsPooledSequences() ) {
forceTableUse = true;
log.info(
"Forcing table use for sequence-style generator due to pooled optimizer selection where db does not support pooled sequences"
);
}
}
To workaround the problem I have created my generator that overrides SequenceStyleGenerator#configure, somethng like:
public void configure(Type type, Properties params, Dialect dialect) throws MappingException {
if (dialect.supportsSequences() && !dialect.supportsPooledSequences()) {
params.setProperty(FORCE_TBL_PARAM, "true");
}
super.configure(type, params, dialect);
Attached is a zip file with a small maven project with unit-test that replicates the problem. It generates DDL for different databases: Hipersonic, Derby, Oracle, MySql, PostgreSQL, MSSQL, DB2, and SAPDB. The data-model contains 2 tables Person and Event in many-to-many relation.
--
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
15 years, 7 months
[Hibernate-JIRA] Created: (HHH-2881) PersistantBag.initializeFromCache can be intercepted by CollectionLoadContext.getLoadingCollection and so corrupt the collection
by Pavol Zibrita (JIRA)
PersistantBag.initializeFromCache can be intercepted by CollectionLoadContext.getLoadingCollection and so corrupt the collection
--------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2881
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2881
Project: Hibernate3
Issue Type: Bug
Environment: Hibernate Entity Manager 3.3.1 GA, oracle,
Reporter: Pavol Zibrita
It can occur that while PersistenBag.initializeFromCache is called to populate the collection from cache, the collection is populated also from CollectionLoadContext.getLoadingCollection, and so, the collection is filled with more data than needed. As the initializeFromCache uses direct access to the property this.bag, it will continue loading the collection. Here is the stack trace of what happens:
PersistentBag.beforeInitialize(CollectionPersister, int) line: xx //here is the same collection reinitialized again, and loaded again
CollectionLoadContext.getLoadingCollection(CollectionPersister, Serializable) line: 127
EntityLoader(Loader).readCollectionElement(Object, Serializable, CollectionPersister, CollectionAliases, ResultSet, SessionImplementor) line: 1003
EntityLoader(Loader).readCollectionElements(Object[], ResultSet, SessionImplementor) line: 646
EntityLoader(Loader).getRowFromResultSet(ResultSet, SessionImplementor, QueryParameters, LockMode[], EntityKey, List, EntityKey[], boolean) line: 591
EntityLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 701
EntityLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 236
EntityLoader(Loader).loadEntity(SessionImplementor, Object, Type, Object, String, Serializable, EntityPersister) line: 1860
EntityLoader(AbstractEntityLoader).load(SessionImplementor, Object, Object, Serializable) line: 48
EntityLoader(AbstractEntityLoader).load(Serializable, Object, SessionImplementor) line: 42
SingleTableEntityPersister(AbstractEntityPersister).load(Serializable, Object, LockMode, SessionImplementor) line: 3044
DefaultLoadEventListener.loadFromDatasource(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 395
DefaultLoadEventListener.doLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 375
DefaultLoadEventListener.load(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 139
DefaultLoadEventListener.proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 195
DefaultLoadEventListener.onLoad(LoadEvent, LoadEventListener$LoadType) line: 103
SessionImpl.fireLoad(LoadEvent, LoadEventListener$LoadType) line: 878
SessionImpl.internalLoad(String, Serializable, boolean, boolean) line: 846
ManyToOneType(EntityType).resolveIdentifier(Serializable, SessionImplementor) line: 557
ManyToOneType.assemble(Serializable, SessionImplementor, Object) line: 196
TypeFactory.assemble(Serializable[], Type[], SessionImplementor, Object) line: 420
CacheEntry.assemble(Serializable[], Object, Serializable, EntityPersister, Interceptor, EventSource) line: 96
CacheEntry.assemble(Object, Serializable, EntityPersister, Interceptor, EventSource) line: 82
DefaultLoadEventListener.assembleCacheEntry(CacheEntry, Serializable, EntityPersister, LoadEvent) line: 553
DefaultLoadEventListener.loadFromSecondLevelCache(LoadEvent, EntityPersister, LoadEventListener$LoadType) line: 508
DefaultLoadEventListener.doLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 357
DefaultLoadEventListener.load(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 139
DefaultLoadEventListener.proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 195
DefaultLoadEventListener.onLoad(LoadEvent, LoadEventListener$LoadType) line: 103
SessionImpl.fireLoad(LoadEvent, LoadEventListener$LoadType) line: 878
SessionImpl.internalLoad(String, Serializable, boolean, boolean) line: 846
ManyToOneType(EntityType).resolveIdentifier(Serializable, SessionImplementor) line: 557
ManyToOneType.assemble(Serializable, SessionImplementor, Object) line: 196
PersistentBag.initializeFromCache(CollectionPersister, Serializable, Object) line: xxx //NOW HERE IS THE Bag initializing from cache, it fails, see top of the stack!!
CollectionCacheEntry.assemble(PersistentCollection, CollectionPersister, Object) line: 35
DefaultInitializeCollectionEventListener.initializeCollectionFromCache(Serializable, CollectionPersister, PersistentCollection, SessionImplementor) line: 130
DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 48
SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1716
PersistentBag(AbstractPersistentCollection).forceInitialization() line: 454
StatefulPersistenceContext.initializeNonLazyCollections() line: 794
QueryLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 241
QueryLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2220
QueryLoader(Loader).listIgnoreQueryCache(SessionImplementor, QueryParameters) line: 2104
QueryLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 2099
QueryLoader.list(SessionImplementor, QueryParameters) line: 378
QueryTranslatorImpl.list(SessionImplementor, QueryParameters) line: 338
HQLQueryPlan.performList(QueryParameters, SessionImplementor) line: 172
SessionImpl.list(String, QueryParameters) line: 1121
QueryImpl.list() line: 79
QueryImpl.getResultList() line: 66
//some stack before, uninportant
Small fix to the PersistantBag has resolved this issue, however I cannot tell if it is correct by some hibernate principles:
public void initializeFromCache(CollectionPersister persister, Serializable disassembled, Object owner)
throws HibernateException {
Serializable[] array = (Serializable[]) disassembled;
int size = array.length;
List<Object> elements = new ArrayList<Object>(size);
for ( int i = 0; i < size; i++ ) {
Object element = persister.getElementType().assemble( array[i], getSession(), owner );
if ( element!=null ) {
elements.add( element );
}
}
beforeInitialize( persister, size );
for ( Object element : elements ) {
this.bag.add( element );
}
}
Difference is, before the this.bag.add(element) was called in first cycle, where the line of getting the element could cause reinitializing the collection and filling it up. There are various possibilities how to fix the problem, but I don't know if the fix is at the right place!
--
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
15 years, 7 months
[Hibernate-JIRA] Created: (HHH-3046) Merge fails on complicated data structure because of cycle references
by Pavol Zibrita (JIRA)
Merge fails on complicated data structure because of cycle references
---------------------------------------------------------------------
Key: HHH-3046
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3046
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4
Environment: Hibernate-3.2.4.ga, db-platform any (h2 & oracle tested)
Reporter: Pavol Zibrita
On complicated object structure, hibernate was unable to merge it correctly because of attaching ID's to the new objects in the tree of the persistent entity. Hibernate cannot cope with cyclic references in this case and it fails with:
javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: org.hibernate.bugtests.data.Transport.pickupNode
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:630)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:237)
at org.hibernate.bugtests.merge.MergeBug.mergeData(MergeBug.java:131)
at org.hibernate.bugtests.merge.MergeBug.testBug(MergeBug.java:149)
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 junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.hibernate.PropertyValueException: not-null property references a null or transient value: org.hibernate.bugtests.data.Transport.pickupNode
at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:290)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:121)
at org.hibernate.ejb.event.EJB3MergeEventListener.saveWithGeneratedId(EJB3MergeEventListener.java:43)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:186)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:123)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:687)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:669)
at org.hibernate.engine.CascadingAction$6.cascade(CascadingAction.java:245)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:456)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:194)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:123)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:687)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:669)
at org.hibernate.engine.CascadingAction$6.cascade(CascadingAction.java:245)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:456)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:194)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:123)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:687)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:669)
at org.hibernate.engine.CascadingAction$6.cascade(CascadingAction.java:245)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:431)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:178)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:123)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:687)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:669)
at org.hibernate.engine.CascadingAction$6.cascade(CascadingAction.java:245)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultMergeEventListener.cascadeOnMerge(DefaultMergeEventListener.java:407)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsPersistent(DefaultMergeEventListener.java:152)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:126)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:53)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:228)
... 20 more
However the value is set correctly.
--
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
15 years, 7 months
[Hibernate-JIRA] Created: (HHH-3532) schema update task should look for foreign key signature
by Dan Allen (JIRA)
schema update task should look for foreign key signature
--------------------------------------------------------
Key: HHH-3532
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3532
Project: Hibernate Core
Issue Type: Improvement
Components: metamodel
Affects Versions: 3.3.1
Reporter: Dan Allen
Priority: Minor
When the schema update task runs, it attempts to locate a foreign key in the database that matches the name provided in the Hibernate mapping information for that particular association. (The name of the foreign key is specified either in the foreign-key attribute in a mapping file or the @ForeignKey annotation). That much works fine. It's when a foreign key name is not provided, common in the case when standard JPA mappings are used, that problems arise.
When a foreign key name is not provided, Hibernate generates a key name as follows:
"FK" + hash code of referenced entity name + hash codes of columns
The chances of an existing foreign key in the database using this generated name is slim to none (every DBA has their own conventions that they follow). Thus, as soon as the scheme update task hits a database under these conditions, duplicate foreign key definitions appear all over the place.
If a foreign key name is not provided in the mapping, Hibernate should be looking instead to see if the signature of the foreign key matches that which is required to fulfill the mapping. In fact, I would even argue that the name is irrelevant and should only be used when actually *creating* the foreign key.
Here is the existing logic in the generateSchemaUpdateScript in Configuration:
ForeignKey fk = (ForeignKey) subIter.next();
boolean create = tableInfo == null || tableInfo.getForeignKeyMetadata( fk.getName() ) == null;
It should be like this instead:
ForeignKey fk = (ForeignKey) subIter.next();
boolean create = tableInfo == null || tableInfo.getForeignKeyMetadata( fk ) == null;
getForeignKeyMetadata should retrieve based on the fk signature rather than the fk name.
--
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
15 years, 7 months
[Hibernate-JIRA] Created: (ANN-698) @Transient property leads to org.hibernate.AnnotationException: Property has an unbound type
by Sebastian Baltes (JIRA)
@Transient property leads to org.hibernate.AnnotationException: Property has an unbound type
--------------------------------------------------------------------------------------------
Key: ANN-698
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-698
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: hibernate3.jar: 3.2.5.ga
hibernate-annotations.jar: 3.3.0.GA
hibernate-commons-annotations.jar: 3.0.0.GA
hibernate-validator.jar: 3.0.0.GA
MySQL
Reporter: Sebastian Baltes
Attachments: log.txt
Transient fields are not ignored in Hibernate. I got an "Property has an unbound type" exception and found no workaround.
Entity:
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Transient;
@Entity
public class Dummy<K> {
@Id
private Long id;
@Transient
transient private K dummyField;
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public K getDummyField() {
return dummyField;
}
public void setDummyField(K dummyField) {
this.dummyField = dummyField;
}
}
Test Code:
EntityManager em = EntityManagerSingleton.get();
EntityTransaction tx = em.getTransaction();
tx.begin();
Dummy a = new Dummy();
em.persist(a);
tx.commit();
Exception:
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at junit.framework.TestSuite.createTest(TestSuite.java:54)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:280)
at junit.framework.TestSuite.<init>(TestSuite.java:140)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.getTest(JUnit3TestLoader.java:102)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.loadTests(JUnit3TestLoader.java:59)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:445)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: javax.persistence.PersistenceException: org.hibernate.AnnotationException: Property de.neise.gena.model.file.Dummy.dummyField has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:258)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:120)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:51)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:33)
at de.neise.gena.model.testbase.BaseTest.<clinit>(BaseTest.java:19)
... 13 more
Caused by: org.hibernate.AnnotationException: Property de.neise.gena.model.file.Dummy.dummyField has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type
at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:993)
at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:833)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:645)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1269)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:150)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:888)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:186)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:246)
... 17 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
15 years, 7 months