This issue was discovered by a user of the Grails Searchable Plugin: http://jira.codehaus.org/browse/GRAILSPLUGINS-482 What happens is that we have 2 classes: Owner and Ownee, where Owner-(1-1)->Ownee. Ownee additionally has a collection (Map or Set in Hibenate sense) which just contains strings. In the Hib mapping, we define set cascade=all on Owner#ownee. Only Ownee is mapped as Searchable - not sure if this is important. Creating and saving the Owner is fine. Try to delete the Owner and you get a NPE in the marshalling code that is ultimately called by the PostCollectionDeleteEvent handler (ie, Compass Hibernate GPS mirroring). This is because the Owner#ownee collection property is one of Hibernate's PersistentSet/PersistentMap classes, but the collection it internally wraps is null, so any method invocations throw NPE. The attached test cases reproduce the bug for both a Map and Set collection type. (They are "within" the context of the Compass source tree, but actually the package/test-case names are awful, and I did not intend that these should become part of added to Compass's own tests - it was just a quick way for me to write a test case) Not sure where the blame for this lies with really - seems unlikely that this should be intended Hibernate behaviour as client code shouldn't have to know about Hib-specific collections and check for such things. Then again maybe Compass shouldn't be trying to a full re-index given that this is a post-delete event.