Pedro's solution allows you to turn serialisation on and off for a given thread
so you won't mess with serialisation by other users (such as the servlet container).
Clever. The only missing piece is an override of the default serialisation to
temporarily flip the switch.
Still, in core it would be much more useful. Users that can configure this kind
of tricks don't tend to make the mistake of referring a session anyway.
Regards,
Erik.
Op 18-11-10 18:31, Martijn Dashorst schreef:
Sessions are meant to be serialized. That's the way they travel
through a cluster, or how sessions are preserved during a server
restart. I'd like to not break that by adding this functionality.
Martijn
On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos<pedros...@gmail.com> wrote:
Ok, I still don't know how interest is to have it in the core. You can do it
at an session extension, like:
1- providing some API
MySession extends Session{
private ThreadLocal<Object> sessionSerializationRestrictor = new
ThreadLocal<Object>();
public void inhibitSerializationOnThread(Object restrictor){
sessionSerializationRestrictor.set(restrictor); }
public void removeSerializationRestriction(){
sessionSerializationRestrictor.set(null); }
private void writeObject(java.io.ObjectOutputStream out) throws
IOException {
if (sessionSerializationRestrictor.get() != null) {
throw some exception explaining that the restrictor do not allow
this serialization;
} else {
out.defaultWriteObject();
} }}
2- providing some Page.IPageSerializer that calls
inhibitSerializationOnThread and removeSerializationRestriction before and
after the page serialization.
On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten<e.vanoos...@grons.nl>wrote:
That won't work in general as some servlet containers (like tomcat)
serialise the session to disk when its idle for too long.
What I meant is that when the page is serialised, it _must_ not contain a
reference to session.
but than some other developers can complain because they are deliberated
serialializing some session.
They won't complain when the exception text specifies why this is wrong.
See Martijn's e-mail in this discussion thread for why it is wrong.
Regards,
Erik.
Op 17-11-10 21:05, Pedro Santos schreef:
I think it is to specific. You can override the Session on your app an
catch
this situation like:
private void writeObject(java.io.ObjectOutputStream out) throws
IOException {
if (Application.get() != null&&
Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
log.info("Session is being serialized in the development
environment, which is an not a desirable behavior.");
}}
but than some other developers can complain because they are deliberated
serialializing some session.
On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoos...@grons.nl
wrote:
Shouldn't serialization fail when it references session/application?
Perhaps only in development mode.
Regards,
Erik.
Op 16-11-10 19:03, Igor Vaynberg schreef:
added a log warning to property models when they reference session.
--
Sent from my SMTP compliant software
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
