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 <[email protected]>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.
