I did not get what you mean by
if everything works fine then there was no reason for keeping them in even if they were not broken.
What I know is that if you try to serialize them you get a NPE (from Tomcat) because they can't be serialised. In other words it works in a non distributed context but, as soon as you want to distribute, login out fails, because you need to persist sessions.
On the other hands, I agree on this
We should better check how they are used and when before setting them to null.
But what will you do then: make them serializable? Or maybe rather change the code which is supposed to use them...
was not suggesting to add Serializable to OFBiz classes;
I did not understand that. I was simply suggesting that developers may add other Objects in session (than the ones we are concerned so far) that would be non serialised, ignoring the issue with logout in distributed applications. But they may want and be able to serialise them. With what you are suggesting this will be hidden and will not let them cope with the issue they may ignore (this is not an obvious issue before you stumble upon it, believe me). For instance (I hope) nobody was aware of this issue before I found it.
I was saying that, if the issue you are facing in distributable app mode is that the session contains non serializable objects (e.g. "security" etc..) then, instead of hardcoding the code in LoginWorker to null them, it would be more elegant (impossible) to hook before the session is serialized and iterate thru the objects in the session and null the ones that don't implement Serializable. In this way, if the system is running a serializable Security implementation, then it will be stored in the session even if in distributable mode.
The code would be also cleaner (no need to add variables and special handling in LoginWorker)
This is going much further than expected. First we must know why those are put in session, what is the need?
hook before the session is serialized
This is done by Tomcat (actually the implementation of ManagerBase used) and, if possible, I guess would need much more work than clarifying the fact that those are really needed in session when login out...