2

We now migrating some ancient project from Wicket 1.3.5 to some newer versions. With version 1.4.23 everything was more or less clear. The trouble appears when we started migration to 1.5.16. Finally I've created simple test-application to tear-down problem. But here was my surprise when even simple two-page application didn't do what it design to do - it shows me 404 on simple change page with setResponsePage().

Here is some test-application code, my debug steps and some thoughts.

ApplicationClass code:

public class WicketTestApplication extends WebApplication {

  public WicketTestApplication() {
    super();
  }

  public static WicketTestApplication get() {
    return (WicketTestApplication) Application.get();
  }

  @Override
  public Class<? extends Page> getHomePage() {

    return FirstPage.class;
  }

  protected void init() {
    super.init();

    getResourceSettings().getStringResourceLoaders().add(new ComponentStringResourceLoader());
    getResourceSettings().getStringResourceLoaders().add(new ClassStringResourceLoader(this.getClass()));
    getResourceSettings().setUseDefaultOnMissingResource(true);
    getResourceSettings().getLocalizer().setEnableCache(false);
    getMarkupSettings().setCompressWhitespace(true);
    getMarkupSettings().setStripComments(true);
    getMarkupSettings().setStripWicketTags(true);
    getDebugSettings().setAjaxDebugModeEnabled(true);
    getRequestCycleSettings().setResponseRequestEncoding("UTF-8");
    getRequestCycleSettings().setRenderStrategy(RenderStrategy.REDIRECT_TO_BUFFER);
  }
}

FirstPage.class code:

public class FirstPage extends MainPage {

  public FirstPage() {

    Form form = new Form("formId");
    add(form);

    WebMarkupContainer message = new WebMarkupContainer("message");
    form.add(message);

    AjaxButton nextBtn = new AjaxButton("nextBtn", new CompoundPropertyModel<String>("Next Page")) {

      private static final long serialVersionUID = 1L;

      @Override
      public void onSubmit(AjaxRequestTarget target, Form<?> form) {

        RequestCycle.get().setResponsePage(SecondPage.class);
      }
    };
    form.add(nextBtn);
  }
}

SecondPage is exactly the same as First one. MainPage is only contains several empty panels so it's irrelevant here.

Regarding problem - click on button calls respenctive method and necessary page constructor called, every thing looked fine at this stage, but browser had another opinion :) For him it were the following tree steps:

  • First request (btn-onClick, ajax) processed fine and redirect to "http:// localhost:9082/testapp/wicket/bookmarkable/com.SomePackage.SecondPage"

  • Second request alos processed fine and redirect to "http:// localhost:9082/testapp/com.SomePackage.SecondPage?2"

  • And finally third request to uppermentioned address failed.

But I still could get my page if manually correct URL by adding "wicket/bookmarkable" construction in it. I started looking for some info regarding such behavior but found nothing. Every article said that it should work out-from-the-box. I've spent huge amount of time playing with Mappers, Handlers and/or RenderStrategies. Here I can note that for cases when RenderStrategy is REDIRECT_TO_RENDER or ONE_PASS_RENDER everything works fine. But it doesn't really mean "straight-from-the-box", as we know that default render strategy is REDIRECT_TO_BUFFER.

While I became feel some desperation, I tried to create another test project from one of those numeruos "wicket-example-articles". This time I've copied whole code with "web.xml" contents and create another WebShere Liberty Profice instance for it. This time is faced it working. After comparison of every bit of two application I found out that only differences were in server features, exactly - in Servlet API. My problem was because I've used old instance where we have jsp-2.2 feature which assumes Servlet API 3.0 version. With 3.1 everithing ok.

Official documentation says:

This Wicket version requires at least the following Servlet API version: Servlet API 2.5 or newer. This is provided by your container, please see the documentation of your container to see which version of the Servlet specification is supported.

So here is the question - am I missed something or Wicket really need only Servlet API 3.1 and (maybe) newer?

P.S. Yeah I know that 1.5.X version is obsolete now. It's just our step in upgrade to 7th one.

1 Answers1

2

Wicket 1.5 should work just fine with Servlet 2.5.

About your problem with the paths:

1) if you mount your page in YourApplication#init() with mountPage("second", SecondPage.class) then Wicket should redirect to /second

2) if you do not mount it explicitly then Wicket should redirect to /wicket/bookmarkable/com.your.package.SecondPage

In both cases if the page is stateful (it is, since you use Ajax components) then it will add ?123, where 123 is a number - the page id.

I do not see any relation between the version of the servlet API with this functionality in Wicket.

martin-g
  • 17,243
  • 2
  • 23
  • 35
  • Hi @martin-g, yeah this is the case when page isn't mounted in Application.init(). In both ways either with 3.0 or 3.1 api version, UrlRenderer class in the end of second request processing (see my mentioned three steps) redirects to `com.SomePackage.SecondPage?123` but with **3.0 API** I get redirect to `http...testapp/com.SomePackage.SecondPage?123` in response header. And wicket return 404 for it. With **3.1 API** I see full path already `http...testapp/wicket/bookmarkable/com.SomePackage.SecondPage?123` in response header and it works. – EtherealDeath Nov 13 '19 at 13:13
  • I have no idea why this might happen, sorry! – martin-g Nov 13 '19 at 13:35