http://wicket.apache.org/. Änderungen siehe hier: https://wicket.apache.org/2012/09/05/wicket-6.0.0-released.html.

Anfang 2009 schrieb ich im Blog:

Darauf hat die Welt gewartet: Wieder ein neues/altes Web-Framework

Apache Click http://incubator.apache.org/click/ heißt es und läuft ab Java 1.4. Super. Kommt damit 5 Jahre zu spät. Also nix mit Annotationen. Schön XML und so. (Click 0.3 gab es auch schon im März 2005, also ist das Projekt nicht wirklich jung.) Das Wort Ajax taucht auf den ganzen Webseiten nicht auf. Immerhin gibt es eine http://incubator.apache.org/click/docs/click-ide.html auf Eclipse 3.4 Basis. Toll die Antwort auf die Frage "Why develop a new Web Application Framework?" Antwort: "Because the existing frameworks did not meet my needs. Struts doesn’t really do much, while Tapestry is too complicated. For a more comprehensive answer please see Why Click." Klar, als ob es nur Struts und Tapestry gibt. Vor 10 Jahren vielleicht. Bei Struts 1.x ist die Zeit schon lange abgelaufen und bei Tapestry 5 hält man sich noch ein wenig mit DI/IoC über Wasser.

Heute, im Jahr 2012, hat es Click zu einem vollständigen Web-Framework geschafft, die Demos (http://click.avoka.com/click-examples/home.htm) sehen von der Funktionalität OK aus, nur etwas altbacken, etwa so wie Windows 3.1 im Vergleich zu Windows 7.

Das letzte Update von Click ist von März 2011, also 1 1/2 Jahr alt. Das war’s dann wohl.

Siehe http://wicket.apache.org/2011/09/07/wicket-1.5-released.html.

Most notable changes

With this release the Wicket team has revised many of its internals. A short list:

• HTML5 components added: EmailTextField, NumberTextField, UrlTextField and RangeTextField
• New inter-component events (explained below)
• Minimum required servlet API is servlet-api 2.5
• All standard validators now extend Behavior to allow for client side validations
• IBehavior has been removed and AbstractBehavior has been deprecated, you should now extend Behaviorinstead
• Simplified the request cycle processing and made it more extensible
• URL handling is now in one place
• Wicket’s rendering code has been greatly simplified
• Improved browser caching support
• ClientSideImageMap replaces old ImageMap
• Better support for running behind proxies with x-forwarded-for header
• Request cycle listeners make it easier to integrate frameworks in your Wicket application
• Consistent naming: methods with Javascript in the name have been renamed to use proper capitalization:JavaScript
• Switching to HTTPS is as simple as configuring a new root mapper to make Wicket HTTPS aware and annotating a page with @RequireHttps

A longer list of changes and improvements can be found in our migration guide.

Servlets zu schreiben gehört nun nicht gerade zu meinem Alltagsaufgaben, aber für ein JSON-Endpoint muss ein Servlet nun doch mit ins Boot. (REST-API geht leider nicht.) Einen Test dafür zu schreiben finde ich selbstverständlich, da ich geil auf grüne Balken bin (nein, nicht die Download-Balken). Es kommen für Servlet-Tests unterschiedliche Ansätze in Betracht, die sich grundsätzlich in 2 Gruppen einteilen lassen:

• Tests mit einem echten (embedded) Servlet-Container
• Mock-Tests

Dass ich ein Jetty-Fan bin ist vielleicht schon in früheren Posts rübergekommen, aber hier lasse ich meinen Lieblingsserver links liegen und gehe auf die Mock-Tests. Gut funktioniert für mich spring-test. Ein Beispiel.

Das Servlet:

package com.tutego.traida.server.service.servlet;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class Raplet extends HttpServlet
{
  private static final long serialVersionUID = 6942655630840028053L;

  @Override
  protected void doGet( HttpServletRequest req, HttpServletResponse resp ) throws ServletException,
      IOException
  {
    resp.getWriter().print( "hello " + req.getParameter( "name" ) );
  }
}

Der Test:

package com.tutego.traida.server.service.servlet;

import javax.servlet.ServletException;
import org.junit.*;
import static org.junit.Assert.*;
import org.springframework.mock.web.*;

public class RapletTest
{
  private Raplet servlet = new Raplet();
  private MockHttpServletRequest request;
  private MockHttpServletResponse response;

  @Before
  public void before() throws ServletException
  {
    servlet.init( new MockServletConfig() );

    this.servlet = new Raplet();
    this.request = new MockHttpServletRequest();
    this.response = new MockHttpServletResponse();
  }

  @Test
  public void doGetTest() throws Exception
  {
    request.setParameter( "name", "tutego" );

    servlet.doGet( request, response );

    assertEquals( "hello tutego", response.getContentAsString() );
  }
}

Einfacher geht’s nun wirklich nicht mehr.

Zum Ablaufen des Tests packe in den Klassenpfad:

• http://grepcode.com/snapshot/repo1.maven.org/maven2/org.springframework/spring-test/3.0.2.RELEASE
• http://grepcode.com/snapshot/repo1.maven.org/maven2/org.springframework/spring-core/3.0.2.RELEASE

Zwar bin ich kein Spring Fan Boy, aber mit 2 Archivdateien brennt die Jar-Hölle nicht so heiß (die Abhängigkeiten sind übertrieben).