I would try to debug the constructor of the page and/or override and
debug life cycle methods of the page and then work up the call stack
why they are executed.

As an example (not necessarily applicable in your case), one could
find this way that the page had expired and Wicket just reconstructed
it which could be surprising. See



On Fri, 8 Mar 2013 23:04:13 +0100, you wrote:

>I've just spent several hours trying to debug a rather strange
>effect with a dropdown and a AjaxFormComponentUpdatingBehavior.
>I have a component which is used in several places of the
>system. It contains a dropdown to which a
>AjaxFormComponentUpdatingBehavior is added. Whenever the user
>selects a value, a label is displayed underneath.
>This component has been in use in different parts of the system
>for quite some time now. After having upgraded to Wicket 6.6, it
>does no longer work - on one particular page. While on all other
>pages it works just fine, on that particular page every time I
>change something, the page reloads (just as if I had attached an
>AjaxFormSubmitBehavior (which of course I had not, actually
>there is not a single one used within the whole project).
>When doing this reloading, my AjaxFormSubmitBehavior's handler
>is never invoked.
>I checked the requests the browser gets to see, and it seems
>like there isn't any difference. Just in case, here's roughly
>what I get on the pages where it works:
>Method: POST
>The next request is an icon for the stuff displayed later.
>On the "bad" page, the request does not look too much different
>(it's just a different page):
>Method: POST
>Only after it, I get the original path, but a redirect:
>Method: GET
>Status Text: 302 (Moved Temporarily)
>Now this indicates that something's going wrong in the Java code
>rather than in Javascript. I tried to find the point where the
>multiplexing is done and from where the Ajax behaviours are
>invoked, but I did not find it.
>Now I feel really clueless. Is there a wellknown Gotcha which
>simply I don't know of? Maybe anybody had the same problem
>before? Or, at least, where should I step into the Wicket code
>in order to find out where it goes wrong?
>Any help appreciated!

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

Reply via email to