[Hibernate-JIRA] Created: (ANN-622) TableGenerator is considered when @Id is defined in MappedSuperclass
by Chandra (JIRA)
TableGenerator is considered when @Id is defined in MappedSuperclass
---------------------------------------------------------------------
Key: ANN-622
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-622
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Affects Versions: 3.3.0.ga
Environment: Hibernate Core 3.2.4.sp1
Hibernate Annotations 3.3.0.GA
hibernate-entitymanager-3.3.1.GA
Reporter: Chandra
Attachments: Cat.java, cat.xml, IdTest.java
We have id defined in a MappedSuperclass (Base) and derrived entity class (Cat). We specify table-generator in an xml file (cat.xml) and use attribute override for ID column. testMappedSuperClassWithTableGenerator in org.hibernate.test.annotations.id.IdTest class fails. If we inline mapped super class with Entity then the test cases succeeds.
With attached debugger we noticed that the TableGenerator is attached to in the begining when the class is in the process of mapping. However, at later point it get overridden by org.hibernate.id.Assigned.
The output with oracle db is,
17:43:51,651 INFO Version:118 - Hibernate Annotations 3.3.0.GA
17:43:51,682 INFO Environment:118 - Hibernate 3.2.4.sp1
17:43:51,697 INFO Environment:118 - hibernate.properties not found
17:43:51,697 INFO Environment:118 - Bytecode provider name : cglib
17:43:51,713 INFO Environment:118 - using JDK 1.4 java.sql.Timestamp handling
17:43:51,869 INFO Version:118 - Hibernate EntityManager 3.3.1.GA
17:43:51,916 DEBUG Ejb3Configuration:97 - Look up for persistence unit: vet
17:43:51,916 DEBUG Ejb3Configuration:76 - Analyse of persistence.xml: file:/C:/projects/sample/target/classes/META-INF/persistence.xml
17:43:52,963 DEBUG DTDEntityResolver:97 - trying to resolve system-id [file:/C:/projects/sample/target/classes/META-INF/xsd/persistence_1_0.xsd]
17:43:52,963 DEBUG EJB3DTDEntityResolver:97 - recognized EJB3 ORM namespace; attempting to resolve on classpath under org/hibernate/ejb
17:43:52,963 DEBUG EJB3DTDEntityResolver:97 - located [file:/C:/projects/sample/target/classes/META-INF/xsd/persistence_1_0.xsd] in classpath
17:43:53,119 DEBUG DTDEntityResolver:97 - trying to resolve system-id [file:/C:/projects/sample/target/classes/META-INF/vets-persistence.xml]
17:43:53,182 DEBUG DTDEntityResolver:97 - trying to resolve system-id [file:/C:/projects/sample/target/classes/META-INF/content-api-persistence.xml]
17:43:53,244 DEBUG PersistenceXmlLoader:76 - Persistent Unit name from persistence.xml: vet
17:43:53,323 DEBUG PersistenceXmlLoader:76 - Persistent Unit name from persistence.xml: content
17:43:53,323 DEBUG Ejb3Configuration:76 - PersistenceMetadata [
name: vet
jtaDataSource: null
nonJtaDataSource: null
transactionType: RESOURCE_LOCAL
provider: null
classes[
org.hibernate.test.annotations.id.Cat ]
packages[
]
mappingFiles[
META-INF/cat.xml
]
jarFiles[
]
hbmfiles: 0
properties[
hibernate.cache.use_query_cache]: false
hibernate.connection.driver_class: oracle.jdbc.driver.OracleDriver
hibernate.dialect: org.hibernate.dialect.Oracle9Dialect
com.intellij.javaee.persistence.datasource: LocalScott
hibernate.cache.use_second_level_cache: false
hibernate.format_sql: true
hibernate.connection.username: scott
hibernate.archive.autodetection: false
hibernate.connection.url: jdbc:oracle:thin:@server:1521:sid
hibernate.bytecode.use_reflection_optimizer: true
hibernate.show_sql: true
hibernate.connection.password: tiger
]]
17:43:53,338 DEBUG JarVisitor:76 - JAR URL from URL Entry: file:/C:/projects/sample/target/classes/META-INF/persistence.xml >> file:/C:/projects/sample/target/classes
17:43:53,338 DEBUG Ejb3Configuration:97 - Detect class: false; detect hbm: false
17:43:53,338 DEBUG JarVisitor:97 - Searching mapped entities in jar/par: file:/C:/projects/sample/target/classes
17:44:01,089 DEBUG AnnotationConfiguration:97 - Process hbm files
17:44:01,089 DEBUG AnnotationConfiguration:97 - Process annotated classes
17:44:01,089 DEBUG AnnotationConfiguration:97 - processing manytoone fk mappings
17:44:01,089 DEBUG Configuration:97 - processing extends queue
17:44:01,089 DEBUG Configuration:97 - processing collection mappings
17:44:01,089 DEBUG Configuration:97 - processing native query and ResultSetMapping mappings
17:44:01,089 DEBUG Configuration:97 - processing association property references
17:44:01,104 DEBUG Configuration:97 - processing foreign key constraints
17:44:01,104 INFO AnnotationConfiguration:118 - Hibernate Validator not found: ignoring
17:44:01,229 INFO DriverManagerConnectionProvider:118 - Using Hibernate built-in connection pool (not for production use!)
17:44:01,229 INFO DriverManagerConnectionProvider:118 - Hibernate connection pool size: 20
17:44:01,229 INFO DriverManagerConnectionProvider:118 - autocommit mode: true
17:44:01,245 INFO DriverManagerConnectionProvider:118 - using driver: oracle.jdbc.driver.OracleDriver at URL: jdbc:oracle:thin:@server:1521:sid
17:44:01,245 INFO DriverManagerConnectionProvider:118 - connection properties: {user=scott, password=tiger, autocommit=true, release_mode=auto}
17:44:01,245 DEBUG DriverManagerConnectionProvider:76 - total checked-out connections: 0
17:44:01,245 DEBUG DriverManagerConnectionProvider:97 - opening new JDBC connection
17:44:01,870 DEBUG DriverManagerConnectionProvider:97 - created connection to: jdbc:oracle:thin:@server:1521:sid, Isolation Level: 2
17:44:01,886 INFO SettingsFactory:118 - RDBMS: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
17:44:01,886 DEBUG DriverManagerConnectionProvider:76 - returning connection to pool, pool size: 1
17:44:01,932 INFO Dialect:118 - Using dialect: org.hibernate.dialect.Oracle9Dialect
17:44:01,948 INFO TransactionFactoryFactory:118 - Transaction strategy: org.hibernate.transaction.JDBCTransactionFactory
17:44:01,948 INFO TransactionManagerLookupFactory:118 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
17:44:01,948 INFO SettingsFactory:118 - Automatic flush during beforeCompletion(): disabled
17:44:01,948 INFO SettingsFactory:118 - Automatic session close at end of transaction: disabled
17:44:01,948 INFO SettingsFactory:118 - JDBC batch size: 15
17:44:01,948 INFO SettingsFactory:118 - JDBC batch updates for versioned data: disabled
17:44:01,948 INFO SettingsFactory:118 - Scrollable result sets: enabled
17:44:01,964 DEBUG SettingsFactory:97 - Wrap result sets: disabled
17:44:01,964 INFO SettingsFactory:118 - JDBC3 getGeneratedKeys(): disabled
17:44:01,964 INFO SettingsFactory:118 - Connection release mode: auto
17:44:01,964 INFO SettingsFactory:118 - Default batch fetch size: 1
17:44:01,964 INFO SettingsFactory:118 - Generate SQL with comments: disabled
17:44:01,964 INFO SettingsFactory:118 - Order SQL updates by primary key: disabled
17:44:01,964 INFO SettingsFactory:118 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
17:44:01,964 INFO ASTQueryTranslatorFactory:118 - Using ASTQueryTranslatorFactory
17:44:01,964 INFO SettingsFactory:118 - Query language substitutions: {}
17:44:01,964 INFO SettingsFactory:118 - JPA-QL strict compliance: enabled
17:44:01,964 INFO SettingsFactory:118 - Second-level cache: disabled
17:44:01,964 INFO SettingsFactory:118 - Query cache: disabled
17:44:01,964 INFO SettingsFactory:118 - Optimize cache for minimal puts: disabled
17:44:01,964 INFO SettingsFactory:118 - Structured second-level cache entries: disabled
17:44:01,979 DEBUG SQLExceptionConverterFactory:76 - Using dialect defined converter
17:44:01,979 INFO SettingsFactory:118 - Echoing all SQL to stdout
17:44:01,979 INFO SettingsFactory:118 - Statistics: disabled
17:44:01,979 INFO SettingsFactory:118 - Deleted entity synthetic identifier rollback: disabled
17:44:01,995 INFO SettingsFactory:118 - Default entity-mode: pojo
17:44:01,995 INFO SettingsFactory:118 - Named query checking : enabled
17:44:02,042 INFO SessionFactoryImpl:118 - building session factory
17:44:02,042 DEBUG SessionFactoryImpl:97 - Session factory constructed with filter configurations : {}
17:44:02,042 DEBUG SessionFactoryImpl:97 - instantiating session factory with properties: {java.vendor=Sun Microsystems Inc., sun.java.launcher=SUN_STANDARD, hibernate.connection.url=jdbc:oracle:thin:@server:1521:sid, sun.management.compiler=HotSpot Client Compiler, hibernate.ejb.discard_pc_on_close=false, hibernate.transaction.flush_before_completion=false, os.name=Windows XP, hibernate.connection.driver_class=oracle.jdbc.driver.OracleDriver, java.vm.vendor=Sun Microsystems Inc., hibernate.dialect=org.hibernate.dialect.Oracle9Dialect, java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition, hibernate.archive.autodetection=false, , hibernate.cache.use_second_level_cache=false, file.encoding=windows-1252, hibernate.use_identifier_rollback=false, java.specification.version=1.5, hibernate.show_sql=true}
17:44:02,464 DEBUG AbstractEntityPersister:97 - Static SQL for entity: org.hibernate.test.annotations.id.Cat
17:44:02,464 DEBUG AbstractEntityPersister:97 - Version select: select CAT_ID from CAT where CAT_ID =?
17:44:02,464 DEBUG AbstractEntityPersister:97 - Snapshot select: select cat_.CAT_ID, cat_.NAME as NAME0_ from CAT cat_ where cat_.CAT_ID=?
17:44:02,464 DEBUG AbstractEntityPersister:97 - Insert 0: insert into CAT (NAME, CAT_ID) values (?, ?)
17:44:02,464 DEBUG AbstractEntityPersister:97 - Update 0: update CAT set NAME=? where CAT_ID=?
17:44:02,464 DEBUG AbstractEntityPersister:97 - Delete 0: delete from CAT where CAT_ID=?
17:44:02,557 DEBUG EntityLoader:97 - Static select for entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=?
17:44:02,557 DEBUG EntityLoader:97 - Static select for entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=?
17:44:02,557 DEBUG EntityLoader:97 - Static select for entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=? for update
17:44:02,557 DEBUG EntityLoader:97 - Static select for entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=? for update nowait
17:44:02,557 DEBUG EntityLoader:97 - Static select for entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=? for update nowait
17:44:02,573 DEBUG EntityLoader:97 - Static select for action ACTION_MERGE on entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=?
17:44:02,573 DEBUG EntityLoader:97 - Static select for action ACTION_REFRESH on entity org.hibernate.test.annotations.id.Cat: select cat0_.CAT_ID as CAT1_0_0_, cat0_.NAME as NAME0_0_ from CAT cat0_ where cat0_.CAT_ID=?
17:44:02,573 DEBUG SessionFactoryObjectFactory:97 - initializing class SessionFactoryObjectFactory
17:44:02,573 DEBUG SessionFactoryObjectFactory:97 - registered: 4028801b1308c9b0011308c9b28d0000 (unnamed)
17:44:02,573 INFO SessionFactoryObjectFactory:118 - Not binding factory to JNDI, no JNDI name configured
17:44:02,573 DEBUG SessionFactoryImpl:97 - instantiated session factory
17:44:02,573 DEBUG SessionFactoryImpl:97 - Checking 0 named HQL queries
17:44:02,573 DEBUG SessionFactoryImpl:97 - Checking 0 named SQL queries
17:44:02,667 DEBUG SessionImpl:97 - opened session at timestamp: 11812634426
17:44:02,667 DEBUG JDBCTransaction:97 - begin
17:44:02,667 DEBUG ConnectionManager:97 - opening JDBC connection
17:44:02,667 DEBUG DriverManagerConnectionProvider:76 - total checked-out connections: 0
17:44:02,667 DEBUG DriverManagerConnectionProvider:76 - using pooled JDBC connection, pool size: 0
17:44:02,667 DEBUG JDBCTransaction:97 - current autocommit status: true
17:44:02,667 DEBUG JDBCTransaction:97 - disabling autocommit
17:44:02,667 DEBUG JDBCContext:76 - after transaction begin
17:44:02,682 DEBUG IdentifierValue:76 - id unsaved-value strategy UNDEFINED
17:44:02,682 DEBUG AbstractSaveEventListener:76 - transient instance of: org.hibernate.test.annotations.id.Cat
17:44:02,682 DEBUG DefaultPersistEventListener:76 - saving transient instance
17:44:02,682 DEBUG AbstractSaveEventListener:97 - generated identifier: 0, using strategy: org.hibernate.id.Assigned
17:44:02,682 DEBUG AbstractSaveEventListener:76 - saving [org.hibernate.test.annotations.id.Cat#0]
17:44:02,698 DEBUG IdentifierValue:76 - id unsaved-value strategy UNDEFINED
17:44:02,698 DEBUG AbstractSaveEventListener:76 - transient instance of: org.hibernate.test.annotations.id.Cat
17:44:02,698 DEBUG DefaultPersistEventListener:76 - saving transient instance
17:44:02,698 DEBUG AbstractSaveEventListener:97 - generated identifier: 0, using strategy: org.hibernate.id.Assigned
17:44:02,698 DEBUG AbstractSaveEventListener:76 - saving [org.hibernate.test.annotations.id.Cat#0]
17:44:02,698 DEBUG AbstractEntityManagerImpl:97 - mark transaction for rollback
javax.persistence.PersistenceException: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [org.hibernate.test.annotations.id.Cat#0]
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:630)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:219)
at org.hibernate.test.annotations.id.VetTest.createCat(VetTest.java:34)
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:585)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:645)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:479)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:715)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:673)
at org.testng.TestRunner.privateRun(TestRunner.java:620)
at org.testng.TestRunner.run(TestRunner.java:480)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:278)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:273)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:253)
at org.testng.SuiteRunner.run(SuiteRunner.java:168)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:987)
at org.testng.TestNG.runSuitesLocally(TestNG.java:951)
at org.testng.TestNG.run(TestNG.java:719)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:122)
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:585)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [org.hibernate.test.annotations.id.Cat#0]
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:168)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:121)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:618)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:592)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:596)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:213)
... 27 more
17:44:02,698 INFO SessionFactoryImpl:118 - closing
17:44:02,714 INFO DriverManagerConnectionProvider:118 - cleaning up connection pool: jdbc:oracle:thin:@server:1521:sid
===============================================
Custom suite
Total tests run: 1, Failures: 1, Skips: 0
===============================================
Process finished with exit code 0
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-3048) README.TXT in /libs poorly organized
by Porter Woodward (JIRA)
README.TXT in /libs poorly organized
------------------------------------
Key: HHH-3048
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3048
Project: Hibernate3
Issue Type: Improvement
Components: documentation
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5
Reporter: Porter Woodward
Priority: Minor
Attachments: _README.txt
While the README.TXT of the /libs directory does contain some hinting about required/optional jar files needed to successfully build/run an application that leverages the Hibernate APIs - it is extemely poorly organized.
It should really have a couple of sections:
Minimal:
List of the minimal, key Jar files needed to make Hibernate work in a no-frills way.
Cache Configuration A:
List of additional Jars for people using a particular cache config.
Cache Configuration B:
Ditto
Java 1.4 Configuration:
List of Jar files needed for Java 1.4 usage...
Etc.
Instead the listing of Jar files is relatively ad-hoc, with no real indication of what Jar files go together and _why_. For instance the optional / required if you're using Treecache jars are scattered throughout the file. That makes it difficult to discern which Jar files are really needed for what.
--
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-961) ConcurrentModificationException in Session.getEntityName()
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-961?page=co... ]
Gail Badner commented on HHH-961:
---------------------------------
Please attach a runnable test case (Java + mapping) to reproduce this issue.
> ConcurrentModificationException in Session.getEntityName()
> ----------------------------------------------------------
>
> Key: HHH-961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-961
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 running on JBoss 4.0.2 with JBoss' Hibernate integration, Database is Oracle 10g R1
> Reporter: Mathias Meyer
>
> I already posted this issue in the Hibernate forums and then tried, on Gavin's advice, to come up with a test case to reproduce the problem. I tried to reproduce this issue in a normal testcase, but didn't succeed with that until now. To not forget about posting this issue, I'm gonna post it anyway.
> Under certain circumstances I get a java.util.ConcurrentModificationException from SessionImpl.getEntityName(). It occures only, when I call getEntityName() on an entity that has just been loaded via Session.load(), and has lazy associations. As you can see in the stacktrace the exception occurs in PersistenceContext.containsProxy(), where the proxy checking and lazy-initializer-fetching happens. The problem seems to be that if the lazy association is being loaded during that call, which definitely seems to happen in my case, it modifies the PersistenceContext's proxiesByKey map. During the iteration the modification is being discovered and accordingly the exception is being thrown.
> The code involved is a lot, so I it's hard for me to separate the problem code from the rest, since there's a whole meta model around the code involved. What I can offer is a patch for the SessionImpl which definitely solved the problem for me. I ran the Hibernate test suites and all seemed to be well with it except the query- and ANTLR-involving ones which somehow don't want to work for me. The patch is inspired by the code in SessionImpl.getIdentifier() which does a similar thing. The following version of SessionImpl.getEntityName() seems to solve the problem:
> public String getEntityName(Object object) {
> if (object instanceof HibernateProxy) {
> LazyInitializer li = ((HibernateProxy) object).getHibernateLazyInitializer();
> if ( li.getSession() != this ) {
> throw new TransientObjectException( "The proxy was not associated with this session" );
> }
> object = li.getImplementation();
> }
> EntityEntry entry = persistenceContext.getEntry(object);
> if (entry==null) throwTransientObjectException(object);
> return entry.getPersister().getEntityName();
> }
> The stacktrace I get is as follows. FYI:
> java.util.ConcurrentModificationException
> at org.apache.commons.collections.ReferenceMap$EntryIterator.checkMod(Unknown Source)
> at org.apache.commons.collections.ReferenceMap$EntryIterator.hasNext(Unknown Source)
> at java.util.AbstractCollection.contains(AbstractCollection.java:99)
> at org.hibernate.engine.PersistenceContext.containsProxy(PersistenceContext.java:468)
> at org.hibernate.impl.SessionImpl.getEntityName(SessionImpl.java:1449)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getOid(HibernatePersistenceManager.java:116)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getObjectById(HibernatePersistenceManager.java:207)
> at de.asdis.acm.api.tools.SoftwareTools.findSoftwareBO(SoftwareTools.java:113)
> at de.asdis.acm.api.tools.SoftwareTools.createSoftwarePackage(SoftwareTools.java:499)
> at de.asdis.acm.api.ejb.ObjectManagerServiceBean.createSoftwarePackage(ObjectManagerServiceBean.java:497)
> at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
> at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:51)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
> at de.asdis.acm.interceptor.jboss.ApiExceptionInterceptor.invoke(ApiExceptionInterceptor.java:33)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at sun.rmi.transport.Transport$1.run(Transport.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:534)
> I tried to reproduce this bug without the container, but haven't been able to do so yet. The fix works fine in our environment, where several thousand objects use this code during testing.
--
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
16 years, 4 months
[Hibernate-JIRA] Created: (HHH-2992) ID generator does not work for objects of type Byte
by Wallace Wadge (JIRA)
ID generator does not work for objects of type Byte
---------------------------------------------------
Key: HHH-2992
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2992
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.5
Environment: Platform-independent, mysql db
Reporter: Wallace Wadge
Priority: Minor
The current ID generator code (org.hibernate.id.IdentifierGeneratorFactory) fails to take into account objects of type Byte (according to the jdbc spec, a TINYINT may be mapped to a Byte or Short - see http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html)
The following code adds this support:
-----
// unhappy about this being public ... is there a better way?
public static Serializable get(ResultSet rs, Type type)
throws SQLException, IdentifierGenerationException {
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 if ( clazz==Byte.class ) {
return rs.getByte(1);
}
else {
throw new IdentifierGenerationException("this id generator generates long, integer, short, byte or string");
}
}
-------------
I'm not sure if we need to add the same logic to the method createNumber in the same file.
Regards.
--
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HBX-276) Generating data for small and large scale testing
by Wallace Wadge (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-276?page=co... ]
Wallace Wadge commented on HBX-276:
-----------------------------------
Hi,
You might wish to have a look at http://sourceforge.net/projects/hibernatepojoge/ for some code to get you started, specifically, in skeleton/src/randomlib/data. There isn't much, but what's there is yours if you want to grab it. Included are a bunch of functions to generate random data of a given type/length eg: generateRandomNumericString(), generateRandomLong(), generateRandomFloat(), etc.
The linked project makes use of them to populate the objects as is proposed in this issue, but probably the code is too tied down to it's code generation to be of direct use.
This library I'm mentioning however should be a drop-in fit since it is not tied down to anything.
Regards
> Generating data for small and large scale testing
> -------------------------------------------------
>
> Key: HBX-276
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-276
> Project: Hibernate Tools
> Issue Type: Improvement
> Components: datagen
> Reporter: Christian Bauer
>
> This is a placeholder item for the data generator kick off. It contains all information available at start.
> Intro
> Overall goal is to provide a library that allows to programmatically (!):
> - mass generation of sample objects filled with sample data
> - objects can be
> o JavaBeans style POJOs
> o Table rows
> - Generated objects are linked together as needed (associations, foreign keys)
> - Generation of sample data can be configured, controlled or customized (custom implementations)
> Modules
> The library is split into two separate Modules
> - Data generation (values)
> - Object/object graph creation (graphs)
> Data generation is completely independent of the object/object graph creation.
> Data Generation
> - Definition of "random" to be used during generation
> o Guaranteed random
> o Pseudo-random with random seed
> o Pseudo-random with provided seed (programmatically reproducible)
> o Advanced: statistical randomness: gauss, peaks ...
> - General settings applied to all value generators
> o Duplicates allowed (max number of duplicates)
> o NULL values allowed (min/max absolute number, percentage)
> - Generation of string based values
> o Random filled strings
> - Min length
> - Max length
> - Upper/lower case configuration (1st upper/lower, rest via the defined character set...)
> - Character set to be used (lots of predefined...)
> - Empty Strings allowed (in addition to min length property)
> o Human readable sentences (e.g. "greeked" text, like lore ipsum...)
> - Min length/Min num of words
> - Max length/Max num of words
> - Word repository to use (built-in or custom)
> o Names
> - Min length/Min num of words
> - Max length/Max num of words
> - Name type (first name, last name, computer usernames)
> o File names
> - Max length
> - Name
> - Extension (fixed, set of predefined, custom list)
> o String concatenations (combination of string generators and fixed text)
> - Generation of numeric values
> o Precision of the results
> o High value (including/excluding this value)
> o Low value (including/excluding this value)
> o Multiple hi/lo ranges
> o Zeros allowed
> o Sequences (g(n+1) OP g(n)+x; OP element of{<,>} and x any value)
> - Generation of date and time value
> o Min date value (absolute, for day, month and/or year)
> o Max date value (absolute, for day, month and/or year)
> o Min time value (absolute, for hour, minute and/or second)
> o Max time value (absolute, for hour, minute and/or second)
> o Allowed day of week
> o Excluded days (predefined set of typical excludes, like Christmas (fix) dynamic (eastern))
> - Binary
> o Min number of bytes
> o Max number of bytes
> o Binary type (set of predefined: gif, jpeg, etc.)
> o Custom set of physical binary files to be used
> - Special Types
> o Boolean
> o Currency values
> o UUIDs (probably realizable with string generator)
> o Lists/sets/bags of generated values
> - Combination of generators
> - Collection type to be used
> Output formatter
> For each generated type there can be various output formatters that convert the type into the needed format.
> - Various numeric formats (BigDecimal, int, long, float, double, etc.)
> - Various date formats
> - Streams
> Output postModifier
> For each generator there can be a custom handler that can execute some custom operations on the generated output, before processing the output formatter.
> Dependent Generation
> Some generators might need the value of other properties of an object to generate a meaningful output. So there is a way to provide a corresponding context for these generators. Context could be:
> - previously generated value(s) of this generator (value repeater, no duplicates in the last n runs, city/zip/country code generation)
> - other generated values (or in general: other properties) for the object they are filled in (note that generators do not know the meaning of an object, since their context is "value generation")
--
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-961) ConcurrentModificationException in Session.getEntityName()
by Marcus Schulte (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-961?page=co... ]
Marcus Schulte commented on HHH-961:
------------------------------------
The issue is still there with version 3.2.5ga.
I'd *really* like to see this fixed. It should be considered "critical" in my opinion, since it leads to "random" crashes of applications.
> ConcurrentModificationException in Session.getEntityName()
> ----------------------------------------------------------
>
> Key: HHH-961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-961
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 running on JBoss 4.0.2 with JBoss' Hibernate integration, Database is Oracle 10g R1
> Reporter: Mathias Meyer
>
> I already posted this issue in the Hibernate forums and then tried, on Gavin's advice, to come up with a test case to reproduce the problem. I tried to reproduce this issue in a normal testcase, but didn't succeed with that until now. To not forget about posting this issue, I'm gonna post it anyway.
> Under certain circumstances I get a java.util.ConcurrentModificationException from SessionImpl.getEntityName(). It occures only, when I call getEntityName() on an entity that has just been loaded via Session.load(), and has lazy associations. As you can see in the stacktrace the exception occurs in PersistenceContext.containsProxy(), where the proxy checking and lazy-initializer-fetching happens. The problem seems to be that if the lazy association is being loaded during that call, which definitely seems to happen in my case, it modifies the PersistenceContext's proxiesByKey map. During the iteration the modification is being discovered and accordingly the exception is being thrown.
> The code involved is a lot, so I it's hard for me to separate the problem code from the rest, since there's a whole meta model around the code involved. What I can offer is a patch for the SessionImpl which definitely solved the problem for me. I ran the Hibernate test suites and all seemed to be well with it except the query- and ANTLR-involving ones which somehow don't want to work for me. The patch is inspired by the code in SessionImpl.getIdentifier() which does a similar thing. The following version of SessionImpl.getEntityName() seems to solve the problem:
> public String getEntityName(Object object) {
> if (object instanceof HibernateProxy) {
> LazyInitializer li = ((HibernateProxy) object).getHibernateLazyInitializer();
> if ( li.getSession() != this ) {
> throw new TransientObjectException( "The proxy was not associated with this session" );
> }
> object = li.getImplementation();
> }
> EntityEntry entry = persistenceContext.getEntry(object);
> if (entry==null) throwTransientObjectException(object);
> return entry.getPersister().getEntityName();
> }
> The stacktrace I get is as follows. FYI:
> java.util.ConcurrentModificationException
> at org.apache.commons.collections.ReferenceMap$EntryIterator.checkMod(Unknown Source)
> at org.apache.commons.collections.ReferenceMap$EntryIterator.hasNext(Unknown Source)
> at java.util.AbstractCollection.contains(AbstractCollection.java:99)
> at org.hibernate.engine.PersistenceContext.containsProxy(PersistenceContext.java:468)
> at org.hibernate.impl.SessionImpl.getEntityName(SessionImpl.java:1449)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getOid(HibernatePersistenceManager.java:116)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getObjectById(HibernatePersistenceManager.java:207)
> at de.asdis.acm.api.tools.SoftwareTools.findSoftwareBO(SoftwareTools.java:113)
> at de.asdis.acm.api.tools.SoftwareTools.createSoftwarePackage(SoftwareTools.java:499)
> at de.asdis.acm.api.ejb.ObjectManagerServiceBean.createSoftwarePackage(ObjectManagerServiceBean.java:497)
> at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
> at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:51)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
> at de.asdis.acm.interceptor.jboss.ApiExceptionInterceptor.invoke(ApiExceptionInterceptor.java:33)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at sun.rmi.transport.Transport$1.run(Transport.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:534)
> I tried to reproduce this bug without the container, but haven't been able to do so yet. The fix works fine in our environment, where several thousand objects use this code during testing.
--
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Gail Badner commented on HHH-1296:
----------------------------------
This has been resolved as a duplicate of HHH-1268. The patch has not been applied.
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Assignee: Diego Pires Plentz
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
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
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Thomas Kappler (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Thomas Kappler commented on HHH-1296:
-------------------------------------
The status is "resolved", but where has the patch been applied? Looks like it hasn't been yet, at least in the SVN annotations from http://anonsvn.jboss.org/repos/hibernate/annotations. Am I looking at the wrong place?
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Assignee: Diego Pires Plentz
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
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
16 years, 4 months