Quantcast

REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
For security reasons we've added a filter to our web application which invalidates session if the session ID is exposed in the URL (disable JSessionID URL encoding). We only accept HttpSession creation if the user allows cookies. But this may be a problem for web crawlers (e.g. Google bot), as they do not use cookies.
With Wicket 6.7.0 we did not have any problem as no page version has been added to bookmarkable URLs by default (no redirect) as long as no form submits occured. Which is sufficient because web crawlers can index the site. After upgrading to Wicket 6.8.0 the page version number is added for each bookmarkable page request and we can not display any page if cookies and Javascript are deactivated in the browser. This results in an endless loop ("The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete."). What causes the new behavior? What has been changed? I reckon this relies to bug https://issues.apache.org/jira/browse/WICKET-5164. The only solution I can think of, is to change the render strategy to REDIRECT_TO_RENDER, as we've had the same problem with Wicket 1.5.x.
Or is there anything else I'm not being aware of?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Sven Meier
Please attach a quickstart to a new jira issue showing the difference
between 6.7.0 and 6.8.0.

Thanks
Sven

On 05/23/2013 11:41 AM, Dirk Forchel wrote:

> For security reasons we've added a filter to our web application which
> invalidates session if the session ID is exposed in the URL (disable
> JSessionID URL encoding). We only accept HttpSession creation if the user
> allows cookies. But this may be a problem for web crawlers (e.g. Google
> bot), as they do not use cookies.
> With Wicket 6.7.0 we did not have any problem as no page version has been
> added to bookmarkable URLs by default (no redirect) as long as no form
> submits occured. Which is sufficient because web crawlers can index the
> site. After upgrading to Wicket 6.8.0 the page version number is added for
> each bookmarkable page request and we can not display any page if cookies
> and Javascript are deactivated in the browser. This results in an endless
> loop ("The page isn't redirecting properly Firefox has detected that the
> server is redirecting the request for this address in a way that will never
> complete."). What causes the new behavior? What has been changed? I reckon
> this relies to bug https://issues.apache.org/jira/browse/WICKET-5164. The
> only solution I can think of, is to change the render strategy to
> REDIRECT_TO_RENDER, as we've had the same problem with Wicket 1.5.x.
> Or is there anything else I'm not being aware of?
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
A simple quickstart application running with Wicket 6.8.0 and Jetty and two mounted pages (stateless?) do not trigger the problem. It might be more difficult to figure out what causes the redirect. Any hint?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Martin Grigorov-4
On Thu, May 23, 2013 at 1:18 PM, Dirk Forchel <[hidden email]>wrote:

> A simple quickstart application running with Wicket 6.8.0 and Jetty and two
> mounted pages (stateless?) do not trigger the problem. It might be more
> difficult to figure out what causes the redirect. Any hint?
>

Clone Wicket code locally and with git bisect you can find which commit
caused the change in the behavior in your app.


>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991p4658993.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
This post was updated on .
Unfortunately I can not build the package. Any help would be appreciated.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project wicket-core: There are test failures.
[ERROR]
[ERROR] Please refer to C:\projects\wicket\wicket-core\target\surefire-reports for the individual test results.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project wicket-core: There are test failures.

Please refer to C:\projects\wicket\wicket-core\target\surefire-reports for the individual test results.
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.

Please refer to C:\projects\wicket\wicket-core\target\surefire-reports for the individual test results.
        at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:83)
        at org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:185)
        at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:159)
        at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:626)
        at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:587)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
        ... 19 more


[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Wicket Core 6.7.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-util/6.7.0-SNAPSHOT/maven-metadata.xml
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-util/6.7.0-SNAPSHOT/wicket-util-6.7.0-SNAPSHOT.pom
[WARNING] The POM for org.apache.wicket:wicket-util:jar:6.7.0-SNAPSHOT is missing, no dependency information available
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-request/6.7.0-SNAPSHOT/maven-metadata.xml
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-request/6.7.0-SNAPSHOT/wicket-request-6.7.0-SNAPSHOT.pom
[WARNING] The POM for org.apache.wicket:wicket-request:jar:6.7.0-SNAPSHOT is missing, no dependency information available
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-util/6.7.0-SNAPSHOT/wicket-util-6.7.0-SNAPSHOT.jar
Downloading: http://repository.apache.org/snapshots/org/apache/wicket/wicket-request/6.7.0-SNAPSHOT/wicket-request-6.7.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.829s
[INFO] Finished at: Fri May 24 06:46:44 CEST 2013
[INFO] Final Memory: 9M/308M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project wicket-core: Could not resolve dependencies for project org.apache.wicket:wicket-core:jar:6.7.0-SNAPSHOT: The following artifacts could not be resolved: org.apache.wicket:wicket-util:jar:6.7.0-SNAPSHOT, org.apache
.wicket:wicket-request:jar:6.7.0-SNAPSHOT: Could not find artifact org.apache.wicket:wicket-util:jar:6.7.0-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
I found the solution by myself ...

"mvn clean -DskipTests package" does the job on my Windows system
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Martin Grigorov-4
I'm still interested what failures there are on Windows.
Most of us develop on Linux/Mac and our CI servers are Linux too.
So we have tests failing on Windows from time to time. But usually it is a
problem in the tests themselves.


On Fri, May 24, 2013 at 10:38 AM, Dirk Forchel <[hidden email]>wrote:

> I found the solution by myself ...
>
> "mvn clean -DskipTests package" does the job on my Windows system
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991p4659009.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
In reply to this post by Martin Grigorov-4
Hi Martin, I could pinpoint the commit which changed the behavior in our application:

git.exe bisect bad

34f43642195058f375d161dbb7cec58b40711423 is the first bad commit
commit 34f43642195058f375d161dbb7cec58b40711423
Author: Martin Tzvetanov Grigorov <mgrigorov@apache.org>
Date:   Fri Apr 19 12:21:04 2013 +0300

WICKET-5083 Page#isPageStateless() may return wrong value

Initialize the page if it is not already when calculating its statefulness

:040000 040000 fc0a2197290a684ebfe415415f1d425fdf43ee2e b723f22ec183769483dfdb9d21b4af0e1b8e5ca1 M wicket-core
Success
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Martin Grigorov-4
We will need a quickstart to debug it.
With this change the calculation whether a page is stateless or not is
postponed to a later phase of the page lifecycle.

A page has the pageId (?X) only if it is stateful.


On Fri, May 24, 2013 at 1:08 PM, Dirk Forchel <[hidden email]>wrote:

> Hi Martin, I could pinpoint the commit which changed the behavior in our
> application:
>
> git.exe bisect bad
>
> 34f43642195058f375d161dbb7cec58b40711423 is the first bad commit
> commit 34f43642195058f375d161dbb7cec58b40711423
> Author: Martin Tzvetanov Grigorov <[hidden email]>
> Date:   Fri Apr 19 12:21:04 2013 +0300
>
> WICKET-5083 Page#isPageStateless() may return wrong value
>
> Initialize the page if it is not already when calculating its statefulness
>
> :040000 040000 fc0a2197290a684ebfe415415f1d425fdf43ee2e
> b723f22ec183769483dfdb9d21b4af0e1b8e5ca1 M      wicket-core
> Success
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991p4659016.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
In reply to this post by Martin Grigorov-4
Here the failure trace:

java.lang.AssertionError
        at org.junit.Assert.fail(Assert.java:92)
        at org.junit.Assert.assertTrue(Assert.java:43)
        at org.junit.Assert.assertTrue(Assert.java:54)
        at org.apache.wicket.markup.html.PackageResourceTest.packageResourceGuard(PackageResourceTest.java:88)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
        at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
        at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
In reply to this post by Martin Grigorov-4
I reckon WICKET-5083 is a bugfix for wrong rendered URLs (stateful pages were rendered without a page version number) which in our case was correct but just as a mistake. It seems, that our pages are stateful and therefore get the page version number (page id ?x) attached. As I described above, in our project this results in an error (endless loop) if cookies are not allowed or if a web crawler wants to index the site, because we don't support session IDs in URLs.
The only solution I can think of, is to mark these pages as "stateless".
What is the correct way to do this? A "stateless" page must be at least bookmarkable and no child component should be stateful.
I can remember that the annotation @StatelessComponent in combination with the StatelessChecker and the method call setStatelessHint(true) was necessary to mark a page as being "stateless".
Is this still necessary? Or what is the preferred way for doing this?

As a quick hack I've already changed our render strategy from REDIRECT_TO_BUFFER to REDIRECT_TO_RENDER. In that case no page version id is attached at all. What could be the flaw for using this render strategy as an alternative?

Thanks for your helping hand.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Martin Grigorov-4
On Fri, May 24, 2013 at 3:22 PM, Dirk Forchel <[hidden email]>wrote:

> I reckon WICKET-5083 is a bugfix for wrong rendered URLs (stateful pages
> were
> rendered without a page version number) which in our case was correct but
> just as a mistake. It seems, that our pages are stateful and therefore get
> the page version number (page id ?x) attached. As I described above, in our
> project this results in an error (endless loop) if cookies are not allowed
> or if a web crawler wants to index the site, because we don't support
> session IDs in URLs.
> The only solution I can think of, is to mark these pages as "stateless".
> What is the correct way to do this? A "stateless" page must be at least
> bookmarkable and no child component should be stateful.
> I can remember that the annotation @StatelessComponent in combination with
> the StatelessChecker and the method call setStatelessHint(true) was
> necessary to mark a page as being "stateless".
> Is this still necessary? Or what is the preferred way for doing this?
>

page.setStatelessHint(false) should be enough to simulate that it is
stateless.
But check the urls of the links inside the page markup. If there is no ?X
then a new page instance will be created to execute the callback method
(e.g. onClick()).
Since you believed in 6.7.0 that the page is stateless I assume you do not
keep any state, so all should be still OK.


>
> As a quick hack I've already changed our render strategy from
> REDIRECT_TO_BUFFER to REDIRECT_TO_RENDER. In that case no page version id
> is
> attached at all. What could be the flaw for using this render strategy as
> an
> alternative?
>

Check the its javadoc in IRequestCycleSettings


>
> Thanks for your helping hand.
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991p4659021.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
You mean setStatelessHint(true) should be enough to simulate that it is stateless (and not setStatelessHint(false)), do you?
Actually we didn't care about whether a page is stateless or not as long as they are bookmarkable.
After a while we've noticed, that stateful pages (with the page version id appended) in connection with our special filter cause the problem with the endless loop (no HTML session can be created) if the user does not allow cookies in his browser or if a web crawler wants to index the site. This problem came up with Wicket 1.5.7 or 1.5.8. After we did a migration to Wicket 6 (version 6.7.0) the problem was gone and no page version id was attached to the URLs anymore (as long as no form was submitted) and we thought all will be fine. But with version 6.8.0 the problem came up again and we were confused about that.
In summary, does this mean, we pages which should be indexed by web crawlers can not be stateful?
I've found this discussion from an older thread http://apache-wicket.1842946.n4.nabble.com/Session-ids-and-search-engine-bots-tc1916506.html#a1916510 with exactly the same problem. And to be honest, I did not expect, that we have to care about that. This should be handled by the web framework itself. But from now on we have to keep an eye on whether our pages are stateless or not.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Martin Grigorov-4
Hi,


On Mon, May 27, 2013 at 8:35 AM, Dirk Forchel <[hidden email]>wrote:

> You mean setStatelessHint(true) should be enough to simulate that it is
> stateless (and not setStatelessHint(false)), do you?
>

Yes, sorry.


> Actually we didn't care about whether a page is stateless or not as long as
> they are bookmarkable.
> After a while we've noticed, that stateful pages (with the page version id
> appended) in connection with our special filter cause the problem with the
> endless loop (no HTML session can be created) if the user does not allow
> cookies in his browser or if a web crawler wants to index the site. This
> problem came up with Wicket 1.5.7 or 1.5.8. After we did a migration to
> Wicket 6 (version 6.7.0) the problem was gone and no page version id was
> attached to the URLs anymore (as long as no form was submitted) and we
> thought all will be fine. But with version 6.8.0 the problem came up again
> and we were confused about that.
> In summary, does this mean, we pages which should be indexed by web
> crawlers
> can not be stateful?
> I've found this discussion from an older thread
>
> http://apache-wicket.1842946.n4.nabble.com/Session-ids-and-search-engine-bots-tc1916506.html#a1916510
> with exactly the same problem. And to be honest, I did not expect, that we
> have to care about that. This should be handled by the web framework
> itself.
> But from now on we have to keep an eye on whether our pages are stateless
> or
> not.
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/REDIRECT-TO-BUFFER-render-strategy-and-Wicket-6-8-0-tp4658991p4659032.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: REDIRECT_TO_BUFFER render strategy and Wicket 6.8.0

Dirk Forchel
Actually I don't see any reason why to redirect for stateless pages, but browsing the source code I found that the default WePageRenderer returns true for org.apache.wicket.request.handler.render.PageRenderer.enableRedirectForStatelessPage().
Should I override this method as well to disable the redirect? But therfore I have to provide my own WebPageRenderer in WebApplication.class.
By the way, we have a bunch of AbstractAjaxBehaviors and AjaxLinks in the component hierarchy which trigger the Page to be "stateful". But I don't have experience with stateless components so I may miss something.
Loading...