Wicket
  1. Wicket
  2. WICKET-4350

Add more programmatic support for web app construction via servlet 3.0

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.4, 6.0.0-beta1
    • Fix Version/s: 1.5.5, 6.0.0-beta1
    • Component/s: wicket
    • Labels:
      None

      Description

      Since servlet 3.0 web applications can be set up completely in code.

      To support this kind of setup wicket should

      • support the manual assignment of an web application instance to WicketFilter
      • support setting the runtime configuration type in WebApplication programmtically through a setter instead of reading web.xml

      sample code for demonstrating the use case:

      public class AppContextListener implements ServletContextListener
      {
      private GuiceContext guiceContext;

      @Override
      public void contextInitialized(ServletContextEvent sce)

      { // create configuration final AppConfig configuration = new WebAppConfig(); // setup guice guiceContext = new GuiceContext(configuration); // create injector final Injector injector = guiceContext.createInjector(); // create wicket application WebApplication application = injector.getInstance(WebApplication.class); application.setConfigurationType(RuntimeConfigurationType.DEVELOPMENT); // create wicket filter WicketFilter filter = new WicketFilter(application); filter.setFilterPath(""); // dynamically add wicket filter final FilterRegistration.Dynamic wicket = sce.getServletContext().addFilter("wicket", filter); // add filter mapping for path '/' wicket.addMappingForUrlPatterns(EnumSet.allOf(DispatcherType.class), true, "/*"); }

      // ...
      }

      1. javax.servlet.ServletContainerInitializer
        0.0 kB
        Martin Grigorov
      2. Start.java
        2 kB
        Martin Grigorov
      3. Initializer.java
        1 kB
        Martin Grigorov

        Activity

        Hide
        Peter Ertl added a comment -

        done in master

        Show
        Peter Ertl added a comment - done in master
        Hide
        Igor Vaynberg added a comment -

        you should add this to the roadmap page

        Show
        Igor Vaynberg added a comment - you should add this to the roadmap page
        Hide
        Peter Ertl added a comment -

        added to roadmap, thanks for pointing out, Igor

        Show
        Peter Ertl added a comment - added to roadmap, thanks for pointing out, Igor
        Hide
        Peter Ertl added a comment -

        Since the change does not break the api contract also applied to wicket-1.5.x

        Show
        Peter Ertl added a comment - Since the change does not break the api contract also applied to wicket-1.5.x
        Hide
        Martin Grigorov added a comment -

        Here is a set of files which make it working in Jetty. Start.java is only needed for embedded Jetty.
        The key is that DefaultServlet needs to be registered as well. Otherwise WicketFilter has nothing to filter and there is no one to serve static resources.

        Show
        Martin Grigorov added a comment - Here is a set of files which make it working in Jetty. Start.java is only needed for embedded Jetty. The key is that DefaultServlet needs to be registered as well. Otherwise WicketFilter has nothing to filter and there is no one to serve static resources.
        Hide
        Peter Ertl added a comment - - edited

        During my tests with my local 'test.war' file I just found out that there are "subtle" differences in the way application servers are scanning for 'META-INF/services'. Depending on the app server it will look for

        (a) folder 'META-INF/services' inside 'test.jar' which is packaged in 'test.war' at package location 'WEB-INF/lib/test.jar'
        (b) folder 'META-INF/services' residing in the root of 'test.war' (not to be confused with the web root in src/main/webapp), not needing a separate test.jar

        I tested on OS X 10.7.3 running Java 1.6.0_29 (64 bit), this is what the servers supported:

        jboss 7.1.1: (a)
        tomcat 7.0.26: (a)
        jetty 8.1.2: (a) + (b)
        glassfish 3: (a) + (b)

        So only (a) seems to work officially...

        Feel free to paste the proper section of the JSR here

        In short:
        To properly execute your service initializer it has to be located in a JAR file at location '/META-INF/services', it will not reliably work in a WAR file though some servers support it!

        Show
        Peter Ertl added a comment - - edited During my tests with my local 'test.war' file I just found out that there are "subtle" differences in the way application servers are scanning for 'META-INF/services'. Depending on the app server it will look for (a) folder 'META-INF/services' inside 'test.jar' which is packaged in 'test.war' at package location 'WEB-INF/lib/test.jar' (b) folder 'META-INF/services' residing in the root of 'test.war' (not to be confused with the web root in src/main/webapp), not needing a separate test.jar I tested on OS X 10.7.3 running Java 1.6.0_29 (64 bit), this is what the servers supported: jboss 7.1.1: (a) tomcat 7.0.26: (a) jetty 8.1.2: (a) + (b) glassfish 3: (a) + (b) So only (a) seems to work officially... Feel free to paste the proper section of the JSR here In short: To properly execute your service initializer it has to be located in a JAR file at location '/META-INF/services', it will not reliably work in a WAR file though some servers support it!
        Hide
        Peter Ertl added a comment -

        To make your life easy you can use spring's

        org.springframework.web.WebApplicationInitializer

        (see javadoc for details)

        Show
        Peter Ertl added a comment - To make your life easy you can use spring's org.springframework.web.WebApplicationInitializer (see javadoc for details)

          People

          • Assignee:
            Peter Ertl
            Reporter:
            Peter Ertl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development