Interesting.
You have put an entity object in the servlet httpsession. The container is trying to serialize the contents of this session somewhere (probably the datastore). This serialization happens outside user-defined filters, and therefore outside the ObjectifyFilter.
Objectify tries to be clever about serialization - if you have loaded an entity, any Ref<?>s that point to that entity get serialized into a DeadRef which holds an actual link to that entity. Thus you can serialize whole entity graphs. However, this requires a "live" Objectify session - which has already been closed at this point.
I'm not quite sure what to do about this.
The "right" answer is that you should not use http sessions - they are a horrid misfeature of the servlet API and a legacy of the early 2000s way of building web apps. Make your server stateless.
The secondmost "right" answer is that you should not store entity objects in the http session. Entity objects are things you store and retrieve from the datastore, not sessions (or other persistent stores). If you absolutely must store something in an httpsession, store a the Key<?> to an entity so you can look it up in your code. Keys serialize just fine.
Getting into the neighborhood of somewhat wrong answers, we could modify Objectify to serialize a DeadRef with a null value if the serialization takes place outside of a live objectify session (eg, ObjectifyFilter). I'm not sure what the real value is here since the entity instance is going to be somewhat broken - full of DeadRefs instead of LiveRefs. Calling Ref<?>.get() will not work. Ref<?> serialization behavior is intended only to make client-server apps easier; it's not intended to survive roundtrips. I'm not particularly inclined to implement this feature because it sounds like a patch for bad architecture, but if you think you have a really compelling use case, tell your story and we'll see.
Jeff