Package org.apache.wicket.protocol.http

Class ReloadingWicketFilter

  • All Implemented Interfaces:
    javax.servlet.Filter
    public class ReloadingWicketFilter
extends WicketFilter
    Custom WicketFilter that reloads the web applications when classes are modified. In order to monitor changes to your own classes, subclass ReloadingWicketFilter and use include and exclude patterns using wildcards. And in web.xml, point to your custom ReloadingWicketFilter instead of the original WicketFilter.

    The built-in patterns are: 

     ReloadingClassLoader.excludePattern("org.apache.wicket.*");
 ReloadingClassLoader.includePattern("org.apache.wicket.examples.*");

    Example. Defining custom patterns 

     public class MyReloadingFilter extends ReloadingWicketFilter
 {
        static
        {
                ReloadingClassLoader.includePattern("com.company.*");
                ReloadingClassLoader.excludePattern("com.company.spring.beans.*");
                ReloadingClassLoader.includePattern("some.other.package.with.wicket.components.*");
        }
 }

    NOTE If you wish to reload com.company.search.Form, you have to make sure to include all classes that reference com.company.search.Form. In particular, if it is referenced in com.company.Application, you will also have to include the latter. And this is viral, as for every class you include, you must check that all classes that reference it are also included.

    It is also possible to add an extra URL to watch for changes using ReloadingClassLoader.addLocation() . By default, all the URLs returned by the parent class loader (ie all URL returned by ClassLoader.getResources(String) with empty String) are registered.

    Important. It can be quite tricky to setup the reloading mechanism correctly. Here are the general guidelines:

    • The order of include and exclude patterns is significant, the patterns are processed sequentially in the order they are defined
    • Don't forget that inner classes are named after YourClass$1, so take that into account when setting up the patterns, eg include YourClass*, not just YourClass
    • To enable back-button support for the reloading mechanism, be sure to put Objects.setObjectStreamFactory(new WicketObjectStreamFactory()); in your application's WebApplication.init() method. Native JDK object serialization will break the reloading mechanism when navigating in the browser's history.
    • It is advisable to exclude subclasses of Session from the the reloading classloader, because this is the only object that remains across application restarts
    • Last but not least, make sure to clear your session cookie before reloading the application home page (or any other bookmarkable page) to get rid of old pages stored in session

    Be sure to carefully read the following information if you also use Spring:

    When using org.apache.wicket.spring.SpringWebApplicationFactory, the application must be a bean with "prototype" scope and the "applicationBean" init parameter must be explicitly set, otherwise the reloading mechanism won't be able to recreate the application.

    WARNING. Be careful that when using Spring or other component managers, you will get ClassCastException if a given class is loaded two times, one time by the normal classloader, and another time by the reloading classloader. You need to ensure that your Spring beans are properly excluded from the reloading class loader and that only the Wicket components are included. When getting a cryptic error with regard to class loading, class instantiation or class comparison, first disable the reloading class loader to rule out the possibility of a classloader conflict. Please keep in mind that two classes are equal if and only if they have the same name and are loaded in the same classloader. Same goes for errors like LinkageError: Class FooBar violates loader constraints, better be safe and disable the reloading feature.

    Author:
    Jean-Baptiste Quenot
    See Also:
    WicketFilter