Re: Problem with WICKET-5426

[Martin Grigorov <mg...@apache.org>]

HI Andrea,

The ticket fixed a problem where a page thinks that it is stateful even
when all stateful components and behaviors are removed/disabled in a later
stage of the page's lifetime.
So the new state that you observe is OK-ish.
The question is why the forms do not submit ? A quickstart will show us.
In the meantime you can use #setStatelessHint(false) in the page(s) where
you see this problem to make them behave as with 6.12.0

Martin Grigorov
Wicket Training and Consulting


On Fri, Jan 31, 2014 at 6:25 PM, Andrea Del Bene <an...@gmail.com>wrote:

> Hi,
>
> I' facing a very weird problem with Wicket 6.13.0. Some stateless forms
> has stopped to submit their value when we upgraded our app to this
> version. I tracked down the commit that is responsable for this problem
> and is the one related to the issue in the object. If I modify the Page
> class rolling back its changes everything works fine again.
> Unfortunately creating a quickstart is really hard and I couldn't
> reproduce the error in a separate project.
> Debugging the code it turns out that the page with my forms was stateful
> with Wicket 6.12.0 and now is stateless.
> Under this conditions, when my form is submitted the condition "if
> (freshPage && (isStateless == false || component == null))" inside
> ListenerInterfaceRequestHandler is true and the listener is not invoked.
> I'm sorry but I don't have any other detail so far to give. I will try
> to isolate the problem in a quickstart during the weekend.
>

Re: Problem with WICKET-5426

[Andrea Del Bene <an...@gmail.com>]

I found that the problem is related to Shiro Security module from 
WicketStuff. Thank you for your kind support Martin!

Re: Problem with WICKET-5426

[Andrea Del Bene <an...@gmail.com>]

Hi,

I investigate the code of my page and it turns out that it had a Link 
which made it stateful. Replacing the Link with a StatelessLink fixes 
the problem. However it still quite strange how I obtained a stateful 
page while the session was kept temporary (i.e the form's listener had 
no session id in its URL).
I will keep on investigating but as I said making a quickstart is very 
difficult.
> HI Andrea,
>
> The ticket fixed a problem where a page thinks that it is stateful even
> when all stateful components and behaviors are removed/disabled in a later
> stage of the page's lifetime.
> So the new state that you observe is OK-ish.
> The question is why the forms do not submit ? A quickstart will show us.
> In the meantime you can use #setStatelessHint(false) in the page(s) where
> you see this problem to make them behave as with 6.12.0
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Fri, Jan 31, 2014 at 6:25 PM, Andrea Del Bene <an...@gmail.com>wrote:
>
>> Hi,
>>
>> I' facing a very weird problem with Wicket 6.13.0. Some stateless forms
>> has stopped to submit their value when we upgraded our app to this
>> version. I tracked down the commit that is responsable for this problem
>> and is the one related to the issue in the object. If I modify the Page
>> class rolling back its changes everything works fine again.
>> Unfortunately creating a quickstart is really hard and I couldn't
>> reproduce the error in a separate project.
>> Debugging the code it turns out that the page with my forms was stateful
>> with Wicket 6.12.0 and now is stateless.
>> Under this conditions, when my form is submitted the condition "if
>> (freshPage && (isStateless == false || component == null))" inside
>> ListenerInterfaceRequestHandler is true and the listener is not invoked.
>> I'm sorry but I don't have any other detail so far to give. I will try
>> to isolate the problem in a quickstart during the weekend.
>>