By "keep a reference to the session in their class" do you mean something
like this?
Are there any pitfalls to doing this?
final Session session = getSession();
add(new Label("userNameLabel", new Model(session.getUser
().getUserName())));
How about this?
final UserDTO dto = session.getUser();
CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
From: Martijn Dashorst <martijn.dasho...@gmail.com>
To: users@wicket.apache.org
Date: 11/20/2010 12:02 PM
Subject: Re: StackOverflowError
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
Notice: This communication, including any attachments, is intended solely
for the use of the individual or entity to which it is addressed. This
communication may contain information that is protected from disclosure
under State and/or Federal law. Please notify the sender immediately if
you have received this communication in error and delete this email from
your system. If you are not the intended recipient, you are requested not
to disclose, copy, distribute or take any action in reliance on the
contents of this information.
