Problem is that there's no single super constructor. For Wicket all
really matters is the IModel interface of which many implementations
exist outside wicket as well. And it is of course not only the model
that is dangerous. Folks can easily keep a reference to the session in
their class, or make a local variable final and reference that inside
an anon-inner class.

It is not possible to make this water tight. As you are about the
first company running into this issue, I'd say it is not worth the
effort trying to fix it.

What we might do is add a check in the serializable checker and ensure
no wicket session ends up in the tree.

Martijn

On Sat, Nov 20, 2010 at 2:27 PM, Douglas Ferguson
<doug...@douglasferguson.us> wrote:
> Why not just throw and illegal argument exception when you try to create a 
> model with a session?
>
> D/
>
> On Nov 19, 2010, at 3:16 AM, Erik van Oosten wrote:
>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to