[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6960?page=c... ] Marek Dominiak edited comment on HHH-6960 at 1/20/12 7:36 AM: -------------------------------------------------------------- In our appliaction we have got this exception as well with exactly the same stack trace. I was trying to prepare a test case but unfortunately it seems to be really hard. For all simple cases (simple domain model) exception is not throws, for our complicated case (quite big domain model) this exception is thrown for some use cases when we try to delete complicated set of somehow connected entities. To create test case I would have to copy 50+ classes which was taking too much time. I have tried to change the source code to add additional check for null: @Override public void onPreRemoveCollection(PreCollectionRemoveEvent event) { CollectionEntry collectionEntry = getCollectionEntry( event ); if ( collectionEntry != null && collectionEntry.getLoadedPersister() != null && !collectionEntry.getLoadedPersister().isInverse() ) { onCollectionAction( event, null, collectionEntry.getSnapshot(), collectionEntry ); } } and it seems that this change helped. All entities we want to create revisions for were created. Some observations while playing with this issue: - it does not matter how many times @Autited is used - whether one or many entities/fields are annotated with @Autited I get exactly the same results when running our tests each time, I get no errors only when all of @Audited are commented out. So that could be either: our configuration or the bug which causes the exception under certain circumstances (how our entities are connected with each other etc.) UPDATE: I forgot to write that I the same results I got when using Mysql and H2. Our application and configuration worked well with version: 3.6.4.Final. I have tried to use hibernate in version 4.0.1.Final. (we have to remain with 3.6.4.Final) was (Author: marekdominiak): In our appliaction we have got this exception as well with exactly the same stack trace. I was trying to prepare a test case but unfortunately it seems to be really hard. For all simple cases (simple domain model) exception is not throws, for our complicated case (quite big domain model) this exception is thrown for some use cases when we try to delete complicated set of somehow connected entities. To create test case I would have to copy 50+ classes which was taking too much time. I have tried to change the source code to add additional check for null: @Override public void onPreRemoveCollection(PreCollectionRemoveEvent event) { CollectionEntry collectionEntry = getCollectionEntry( event ); if ( collectionEntry != null && collectionEntry.getLoadedPersister() != null && !collectionEntry.getLoadedPersister().isInverse() ) { onCollectionAction( event, null, collectionEntry.getSnapshot(), collectionEntry ); } } and it seems that this change helped. All entities we want to create revisions for were created. Some observations while playing with this issue: - it does not matter how many times @Autited is used - whether one or many entities/fields are annotated with @Autited I get exactly the same results when running our tests each time, I get no errors only when all of @Audited are commented out. So that could be either: our configuration or the bug which causes the exception under certain circumstances (how our entities are connected with each other etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6960?page=c... ] Gail Badner commented on HHH-6960: ---------------------------------- Adam, is this broken in 3.6.9? If so, should the fix be backported to 3.6.10? Thanks, Gail -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6960?page=c... ] Marek Dominiak commented on HHH-6960: ------------------------------------- @Adam I was trying to do that for many hours but still can't create simple (or even complex) test case which can be included here. Our domain model is about 150++ classes and we use most of the features of Hibernate mappings, I can't narrow the problem down. I gave a honest try to create this test case ... I hope someone will be able to create this test case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6960?page=c... ] Adam Warski commented on HHH-6960: ---------------------------------- That's bad about the test case ... with the changes, did you verify (manually), that the audit is properly written? Adam -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Leon Pennings commented on HHH-6960: ------------------------------------ I ran into the same issue. It happened to me on nested objects, so where object A has a parentObject of type A too. Then on a delete of a random object (even without a parentObject) I had a collectionEntry object with all null fields. Funny thing is this happened on am object that did not have the @Audited annotation, nor was it referenced in any way by an @Audited object -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Adam Warski commented on HHH-6960: ---------------------------------- @Leon If you would have a test case, that would be great :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Leon Pennings commented on HHH-6960: ------------------------------------ I tried setting up a simple test case, in which case I can't reproduce the problem - it only happens in our production code. The class tested has 3 collections. When the error does not occur, I have 3 CollectionEntry. When it does occur I have 4 CollectionEntry objects, so one extra. The extra one has all null values. For now I added the nullcheck, in which case all tests succeeds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Leon Pennings commented on HHH-6960: ------------------------------------ I have existing collections for the other 3. The 4th one should not be present as there is no collection for it to map to. Maybe that is why all its attributes are null. Maybe some proxy object that is being analysed? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Kevin Jordan commented on HHH-6960: ----------------------------------- I don't have any Sets of any type in my classes. Any Collection I have is a List with an ArrayList implementation. I do have quite a few @ManyToMany, so it's probably related to that with some certain Collection types. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Paul Taylor commented on HHH-6960: ---------------------------------- I have also started getting this error during a criteria query, the change that seems to have introduced this problem is that Im running a SQL query (using Hibernate) before I run the criteria query, if I remove the SQL Query the problem does not occur. Also if I set the flush mode of the session to FlushMode.ALWAYS that also work rounds the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] ms edited comment on HHH-6960 at 4/14/12 4:35 PM: -------------------------------------------------- I too have the same issue. Unable to recreate in unit test but able to in live run. Couple of notes on my entity: - not audited, nor directly related to audited entites. - the offending entity collection is a child of the entity that's being persisted. - collection entity class has 3 items related back to it through oneToMany relationships. Their definition is as follows: @OneToMany(mappedBy = "sourceField", fetch = FetchType.EAGER) private List<TableMapplet> sourceMapplets; @OneToMany(mappedBy = "targetField", fetch = FetchType.EAGER) private List<Mapplet> targetMapplets; @OneToMany(cascade = CascadeType.ALL, mappedBy = "column", fetch = FetchType.EAGER) private List<IndexColumn> indexColumns; What is occurring in hibernate in steps: 1) "org.hibernate.engine.spi.ActionQueue#executeActions()" is executing "executeActions( collectionRemovals );" where "collectionRemovals" has 15 items... its those 3 relationship owning entities, mentioned earlier, repeated over and over again. so cycling through 5 five times. These actions are executed by the private "executeActions()" method. 2) "org.hibernate.action.internal.CollectionRemoveAction#preRemove()" creates the event object. It is here where "getPersister()" is called in event constructor to add the appropriate "loadedPersister" then executes the listener. 3) "org.hibernate.envers.event.EnversPreCollectionRemoveEventListenerImpl#onPreRemoveCollection()" called by (step 2) where it checks for loadedPersister (loaded previously) and determines if inverse, which is false and continues on for all 3 varying items. So what is stumping me is that on the 4th iteration (step 1 loop) the same getPersister() object from the 1st iteration is used in the event constructor (step 2 from above). All is good. However, when the code moves into (step 3) "onPreRemoveCollection()" getLoadedPersister() returns null. I don't see anything in "CollectionRemoveAction" nor in "ActionQueue" that could remove it and obviously it had the object in the 4th iteration. As per the enver's side only the listener is called as far as i can tell, so no clean up job to follow unless there's some weaving going on that i don't see. Any help in resolving this issue would greatly be appreciated. Its a showstopper for me. was (Author: mosgjig): I too have the same issue. Unable to recreate in unit test but able to in live run. Couple of notes on my entity: - not audited, nor directly related to audited entites. - the offending entity collection is a child of the entity that's being persisted. - collection entity class has 3 items related back to it through oneToMany relationships. Their definition is as follows: @OneToMany(mappedBy = "sourceField", fetch = FetchType.EAGER) private List<TableMapplet> sourceMapplets; @OneToMany(mappedBy = "targetField", fetch = FetchType.EAGER) private List<Mapplet> targetMapplets; @OneToMany(cascade = CascadeType.ALL, mappedBy = "column", fetch = FetchType.EAGER) private List<IndexColumn> indexColumns; What is occurring in hibernate in steps: 1) "org.hibernate.engine.spi.ActionQueue#executeActions()" is executing "executeActions( collectionRemovals );" where "collectionRemovals" has 15 items... its those 3 relationship owning entities, mentioned earlier, repeated over and over again. so cycling through 5 five times. These actions are executed by the private "executeActions()" method. 2) "org.hibernate.action.internal.CollectionRemoveAction#preRemove()" creates the event object. It is here where "getPersister()" is called in event constructor to add the appropriate "loadedPersister" then executes the listener. 3) "org.hibernate.envers.event.EnversPreCollectionRemoveEventListenerImpl#onPreRemoveCollection()" called by (step 2) where it checks for loadedPersister (loaded previously) and determines if inverse, which is false and continues on for all 3 varying items. So what is stumping me is that on the 4th iteration the same getPersister() object from the 1st iteration is used in the event constructor (step 2 from above). All is good. However, when the code moves into (step 3) "onPreRemoveCollection()" getLoadedPersister() returns null. I don't see anything in collectionRemoveAction nor in ActionQueue that could remove it and obviously it had the object in the 4th iteration. As per the enver's side only the listener is called as far as i can tell, so no clean up job to follow unless there's some weaving going on that i don't see. Any help in resolving this issue would greatly be appreciated. Its a showstopper for me. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Gail Badner reassigned HHH-6960: -------------------------------- Assignee: Gail Badner (was: Adam Warski) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] ms commented on HHH-6960: ------------------------- Verified that removing auditing annotation from entities averted the logic flow mentioned earlier, thus avoiding any errors. In step 2 listenerGroup.isEmpty() was true, therefore skipping step 3 in my previous comment. The envers dependency was still present as I have dao logic to read the audit tables. This did not present any issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Stefan Hildebrandt commented on HHH-6960: ----------------------------------------- Issue is reproducible in 4.1.1.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-6960: --------------------------------- https://issues.jboss.org/browse/JBPAPP-8842 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Scott Albertine updated HHH-6960: --------------------------------- Attachment: hibernateBugProofWithSchema.zip Whoops, forgot to include the schema create script in the zip, if a passing admin could delete the old hibernateBugProof.zip and keep the WithSchema one, that'd be great. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Gail Badner commented on HHH-6960: ---------------------------------- Scott Albertine, thanks for the test case. I'm able to reproduce this now and I'm looking into this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Gail Badner updated HHH-6960: ----------------------------- Component/s: (was: envers) core Fix Version/s: 4.1.4 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-6960?page=com.atlassian.jira.plug... ] Gail Badner resolved HHH-6960. ------------------------------ Resolution: Fixed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira