Likely long term fix is to update the org.hibernate.cache.TreeCache class. But, as a temporary workaround for the Stacks 1.1 release, I have implemented a new version of org.hibernate.cache.TreeCache in the EJB3 namespace, and updated TreeCacheProviderHook to use it.

Updated version (o.j.ejb3.entity.JBCCache):

Makes use of JBC's marshalling API to register a deployment's classloader with JBC and activate the relevant region when it is constructed. When the destroy() method is called, the region is inactivated and the classloader unregistered.

Exception to this are the special regions named "org.hibernate.cache.StandardQueryCache" and "org.hibernate.cache.UpdateTimestampsCache", which

1) should not have a particular classloader registered with them, as they may be used by multiple deployments.
2) should not be inactivated when a particular JBCCache instance is destroyed, as other deployments may be using them.

UpdateTimestampsCache does not actually replicate any custom classes, so the special handling for it in JBCCache is just to make sure JBCCache doesn't break anything.

StandardQueryCache does have the potential to replicate classes, but since no classloader can be registered with it's cache region, such a replication attempt will fail. As a workaround, if the region's name is "org.hibernate.cache.StandardQueryCache", JBCCache will not replicate any queries placed in the region, but rather will only cache them locally.