[Hibernate-JIRA] Created: (HHH-2204) transient field make Configuration deserializing error
by ronald feng (JIRA)
transient field make Configuration deserializing error
-------------------------------------------------------
Key: HHH-2204
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2204
Project: Hibernate3
Type: Bug
Components: build
Versions: 3.1.3
Environment: hibernate 3.1.3
database: HSQLDB
Reporter: ronald feng
[code]
Configuration configuration=null;
try {
Configuration configurationSerializable = new Configuration();
FileOutputStream fos = new FileOutputStream("serial");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(configurationSerializable);
oos.flush();
oos.close();
} catch (FileNotFoundException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
catch (IOException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
try {
FileInputStream fis = new FileInputStream("serial");
ObjectInputStream ois = new ObjectInputStream(fis);
configuration = (Configuration) ois.readObject();
ois.close();
} catch (FileNotFoundException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
catch (IOException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
catch (ClassNotFoundException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
if(configuration!=null)
{
SessionFactory sessionFactory = configuration.configure().buildSessionFactory();
}
}
[/code]
protected transient Map typeDefs;
the typeDefs will be null after deserializing.
[code]Exception in thread "main" java.lang.NullPointerException
at org.hibernate.cfg.Mappings.getTypeDef(Mappings.java:376)
at org.hibernate.cfg.HbmBinder.bindSimpleValueType(HbmBinder.java:1161)
at org.hibernate.cfg.HbmBinder.bindSimpleValue(HbmBinder.java:1129)
at org.hibernate.cfg.HbmBinder.bindSimpleId(HbmBinder.java:400)
at org.hibernate.cfg.HbmBinder.bindRootPersistentClassCommonValues(HbmBinder.java:343)
at org.hibernate.cfg.HbmBinder.bindRootClass(HbmBinder.java:282)
at org.hibernate.cfg.HbmBinder.bindRoot(HbmBinder.java:153)
at org.hibernate.cfg.Configuration.add(Configuration.java:386)
at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:427)
at org.hibernate.cfg.Configuration.addResource(Configuration.java:482)
at org.hibernate.cfg.Configuration.parseMappingElement(Configuration.java:1465)
at org.hibernate.cfg.Configuration.parseSessionFactory(Configuration.java:1433)
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1414)
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1390)
at org.hibernate.cfg.Configuration.configure(Configuration.java:1310)
at org.hibernate.cfg.Configuration.configure(Configuration.java:1296)
at org.rzeus.hibernate.test.TestSerializeAndTransient.main(TestSerializeAndTransient.java:50)
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)[/code]
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-3294) Version incorrectly incremented for unchanged persistent entity that is parent of a one to many relationship
by Raymond Chapman (JIRA)
Version incorrectly incremented for unchanged persistent entity that is parent of a one to many relationship
------------------------------------------------------------------------------------------------------------
Key: HHH-3294
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3294
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.4.sp1
Environment: 3.2.4.sp1, Oracle 10g
Reporter: Raymond Chapman
Attachments: versionbumpissue.zip
Given a persisted parent entity and a single persisted child entity involved in a one to many relationship where children are defined in parent HBM file to include merge and persist cascade action, we find that loading the parent and child in a transaction followed by a merge of the parent (no updates performed on either child or parent), and then a transaction commit will increment the version of the parent by 1.
In attached zip I've isolated the problem in a new test testNoExtraUpdatesOnPersistentMergeVersionedWithCollection(), displayed below, added to org/hibernate/test/ops/MergeTest.java. It fails when parent is checked for updates following transaction commit. While the behavior was observed originally against 3.2.4.sp1, I can also reproduce in 3.2.6. In our system this issue causes org.hibernate.StaleObjectStateException exceptions when load is applied.
I believe I've tracked down the origin of the failure. The merge(persistentParent) call results in child collection of parent being cleared, and consequently marked dirty. This happens when org.hibernate.type.CollectionType method replaceElements() is invoked as part of processing cascade action for merge on parent. It seems dirty flag should be reset after call to this method by CollectionType.replace(), performed when original==target. I see a similar effort was applied to replaceElements() but unfortunately this has no impact for this particular test scenario. I've applied a change to CollectionType.replace() to reset dirty flag if 'original' object was not dirty upon method entry. This resolves the issue for both 3.2.4.sp1 and 3.2.6 and I don't see any adverse impact to execution of Hibernate tests against HSQL. The updated CollectionType class is supplied in attached zip (deltas displayed below).
Definition of children for parent in HBM definition OptLockEntity of org/hibernate/test/ops:
<set name="children"
inverse="true"
cascade="persist,merge,save-update,evict,delete">
<key column="parent"/>
<one-to-many class="VersionedEntity"/>
</set>
Index: test/org/hibernate/test/ops/MergeTest.java
===================================================================
--- test/org/hibernate/test/ops/MergeTest.java (revision 14669)
+++ test/org/hibernate/test/ops/MergeTest.java (working copy)
@@ -248,6 +248,56 @@
cleanup();
}
+ public void testNoExtraUpdatesOnPersistentMergeVersionedWithCollection() throws Exception {
+ Session s = openSession();
+ s.beginTransaction();
+ VersionedEntity parent = new VersionedEntity( "parent", "parent" );
+ VersionedEntity child = new VersionedEntity( "child", "child" );
+ parent.getChildren().add( child );
+ child.setParent( parent );
+ s.persist( parent );
+ s.getTransaction().commit();
+ s.close();
+
+ clearCounts();
+
+ // parent is now detached, but we have made no changes. so attempt to merge it
+ // into this new session; this should cause no updates...
+ s = openSession();
+ s.beginTransaction();
+ // load parent so that merge will follow entityIsPersistent path
+ VersionedEntity persistentParent = ( VersionedEntity ) s.get( VersionedEntity.class, parent.getId() );
+ // load children
+ VersionedEntity persistentChild = ( VersionedEntity ) persistentParent.getChildren().iterator().next();
+ VersionedEntity mergedParent = ( VersionedEntity ) s.merge( persistentParent ); // <-- This merge leads to failure
+ s.getTransaction().commit();
+ s.close();
+
+ assertUpdateCount( 0 );
+ assertInsertCount( 0 );
+ assertEquals( "unexpected parent version increment", parent.getVersion(), mergedParent.getVersion() );
+ VersionedEntity mergedChild = ( VersionedEntity ) mergedParent.getChildren().iterator().next();
+ assertEquals( "unexpected child version increment", child.getVersion(), mergedChild.getVersion() );
+
+ ///////////////////////////////////////////////////////////////////////
+ // as a control measure, now update the node once it is loaded and
+ // make sure we get an update as a result...
+ s = openSession();
+ s.beginTransaction();
+ persistentParent = ( VersionedEntity ) s.get( VersionedEntity.class, parent.getId() );
+ persistentParent.setName( "new name" );
+ persistentParent.getChildren().add( new VersionedEntity( "child2", "new child" ) );
+ persistentParent = ( VersionedEntity ) s.merge( persistentParent );
+ s.getTransaction().commit();
+ s.close();
+ assertUpdateCount( 1 );
+ assertInsertCount( 1 );
+ ///////////////////////////////////////////////////////////////////////
+
+// cleanup();
+ }
+
+
public void testPersistThenMergeInSameTxnWithVersion() {
Session s = openSession();
Transaction tx = s.beginTransaction();
Index: src/org/hibernate/type/CollectionType.java
===================================================================
--- src/org/hibernate/type/CollectionType.java (revision 14669)
+++ src/org/hibernate/type/CollectionType.java (working copy)
@@ -521,7 +521,18 @@
//get the elements back into the target
//TODO: this is a little inefficient, don't need to do a whole
// deep replaceElements() call
- replaceElements( result, target, owner, copyCache, session );
+ if ( target instanceof PersistentCollection ) {
+ if ( ! ( ( PersistentCollection ) target ).isDirty() ) {
+ replaceElements( result, target, owner, copyCache, session );
+ ( ( PersistentCollection ) target ).clearDirty();
+ }
+ else {
+ replaceElements( result, target, owner, copyCache, session );
+ }
+ }
+ else {
+ replaceElements( result, target, owner, copyCache, session );
+ }
result = target;
}
--
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, 11 months
[Hibernate-JIRA] Commented: (HHH-1718) Have multiple bag fetches revert to subselect fetching for all but one of the bags
by Morten Andersen-Gott (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718?page=c... ]
Morten Andersen-Gott commented on HHH-1718:
-------------------------------------------
"Violation of what spec? I am always so amazed we passed the TCK with all these "spec violations" floating around :) "
Aaah! A Hibernate team classic. It is these types of helpful comments that Hibernate users and issue reporters have grown so accustomed too. It is what makes using Hibernate such a joy, compared to professional open source, such as Spring!!
"We passed the TCK, ergo; we are spec compliant. QED" The spec is the written document, not the test. It is unlikely that the TCK will be able to cover every aspect of the spec, and this is obviously the case with JPA.
> Have multiple bag fetches revert to subselect fetching for all but one of the bags
> ----------------------------------------------------------------------------------
>
> Key: HHH-1718
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1718
> Project: Hibernate3
> Issue Type: Improvement
> Components: core, query-criteria, query-hql
> Reporter: Steve Ebersole
> Assignee: Steve Ebersole
> Fix For: hql+collection
>
> Attachments: hibernate_eksempel.zip
>
>
> Follow on to HHH-1413. Multiple bag fetches were simply disallowed as the resolution to that particular case in the interest of working around that issue.
> The correct longer term solution is to not fetch all the bags at once, ideally reverting to subselect fetching for all but one of the bags.
--
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, 11 months
[Hibernate-JIRA] Created: (EJB-368) Detached entity not reported consistently
by Henriette Harmse (JIRA)
Detached entity not reported consistently
-----------------------------------------
Key: EJB-368
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-368
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.3.2.GA
Environment: ejb3-persistence-1.0.1.GA.jar
hibernate-entitymanager-3.3.2.GA.jar
hibernate-3.2.6.ga.jar
postgresql-8.3-603.jdbc3.jar
jdk 1.5.0_13/jdk 1.6.0_06
Windows XP
Reporter: Henriette Harmse
Attachments: HibernateTest.zip
The attached code does not fail consistently with a "detached entity" exception.
Under jdk 1.5 (tested with jdk 1.5.0_10 & 1.5.0_13) it fails with a detached entity exception which is correct. Running the same code against jdk 6 (tested with jdk 1.6.0_06 & jdk 1.6.0_03) passes and the records are written to the database.
The same code works against jdk 1.5 (and jdk 6) as well when the <mapping-file>META-INF/emailAddress.xml</mapping-file> and <class>example.domain.EmailAddress</class> are commented out from the persistence.xml file.
The fact that this code does not fail consistently could cause developers to use Hibernate incorrectly which may only be apparent much later into the project.
In order to run the example:
1. Create Postgres database called "example".
2. Create "example" user with username and password "example"
3. Edit the run.cmd and build.cmd files to set your JAVA_HOME.
4. Run "build.cmd".
5. Run "run.cmd".
--
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, 11 months
[Hibernate-JIRA] Commented: (HHH-1804) Empty 'FetchingScrollableResultsImpl' throws SQLException
by Martin Thelian (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804?page=c... ]
Martin Thelian commented on HHH-1804:
-------------------------------------
Will this patch be included into an official release in the near future? Thanks.
> Empty 'FetchingScrollableResultsImpl' throws SQLException
> ---------------------------------------------------------
>
> Key: HHH-1804
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804
> Project: Hibernate3
> Issue Type: Bug
> Reporter: Maarten Winkels
> Attachments: EmptyFetchJoinScrollTest.java, scroll-join-fetch-empty.patch
>
>
> When scrolling a HQL query with join fetch on a collection, that doesn't return any results, the following execption occurs:
> org.hibernate.exception.GenericJDBCException: could not perform sequential read of results (forward)
> at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:386)
> at org.hibernate.impl.FetchingScrollableResultsImpl.next(FetchingScrollableResultsImpl.java:55)
> at org.hibernate.test.joinfetch.EmptyFetchJoinScrollTest.testFetchJoinEmptyScroll(EmptyFetchJoinScrollTest.java:21)
> 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 junit.framework.TestCase.runTest(TestCase.java:154)
> at org.hibernate.test.TestCase.runTest(TestCase.java:161)
> 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.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.sql.SQLException: No data is available
> at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
> at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
> at org.hsqldb.jdbc.jdbcResultSet.checkAvailable(Unknown Source)
> at org.hsqldb.jdbc.jdbcResultSet.getColumnInType(Unknown Source)
> at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source)
> at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source)
> at org.hibernate.type.StringType.get(StringType.java:18)
> at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:113)
> at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:102)
> at org.hibernate.loader.Loader.getKeyFromResultSet(Loader.java:1088)
> at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:375)
> ... 18 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, 11 months
[Hibernate-JIRA] Created: (HHH-3019) LAZY 1:1 (self-) reference with Inheritance ---> WRONG INTERFACES implemented by Javassist/CGLIB created Proxies
by S.Schnabl (JIRA)
LAZY 1:1 (self-) reference with Inheritance ---> WRONG INTERFACES implemented by Javassist/CGLIB created Proxies
----------------------------------------------------------------------------------------------------------------
Key: HHH-3019
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3019
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4
Environment: Win-XP, Jboss 4.2.2.GA, Java 1.6, Hibernate 3.2.4Sp1
Reporter: S.Schnabl
Priority: Blocker
Attachments: Hibernate_lazy_1-to-1_with-proxy_TestCase.rar
Hello, following simple testcase:
EntityC, EntityB, EntityA are interfaces and have their respective implementations EntityCImpl, EntityBImpl, EntityAImpl. Inheritance structure is following:
-> EntityC extends EntityB extends EntityA.
Now EntityA has a 1:1 reference for another Entity, which at least must implement Interface 'EntityA' itself. These relation is described like following:
@OneToOne(fetch = FetchType.LAZY, targetEntity = EntityAImpl.class)
public EntityA getNextEntity() {
return this.nextEntity;
}
Testcase: ( for complete testcase and entity structure see attached zip-file. Sorry, but only a jboss-variante attached due to short of time. Simply deploy the server.ear file from release-directory and run the src/client/TestCaseClient.java)
Mainly the testcase does the following:
// create a entityA
EntityA a = new EntityAImpl();
this.em.persist(a);
// create a EntityB, which inherits from EntityA
EntityB b = new EntityBImpl();
this.em.persist(b);
// link B to A
a.setNextEntity(b);
// load EntityA, which has an 1:1 attached EntityB(-Proxy!)
EntityA a = this.em.find(EntityAImpl.class, idEntityA);
// load attached EntityB - should be from expected type EntityB(-Proxy!)
Object b = a.getNextEntity();
// Now check, which Interfaces these EntityB implements: should be
// EntityA and EntityB, but NOT EntityC
if (b instanceof HibernateProxy)
System.out.println("Loaded object is instanceof " + HibernateProxy.class.getSimpleName()); // true
if (b instanceof EntityB)
System.out.println("Loaded object is instanceof " + EntityBImpl.class.getSimpleName()); // true
if (b instanceof EntityC)
System.out.println("Loaded object is instanceof " + EntityCImpl.class.getSimpleName()); // TRUE - ERROR !!!!!!!! That's a bug ! We loaded an EntityB which CANNOT be of Type EntityC !!!!
As you can see, the proxy implents wrongly the Interface EntityC, which must NOT implemented, cause we have only an EntityB linked to EntityA!!
--
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, 11 months