Using the NetBeans Platform on the Server with Wicket on the Client

The Web deployment descriptor is up to you, since it depends on how many and which frameworks you want to use with your application; each one will need a specific configuration. This is why the code I've just introduced has been packaged as a simple .jar library, rather than a complete .war application. 

For instance, this is how I integrated Wicket in blueOcean:

    <filter>
        <filter-name>WicketFilter</filter-name>
        <filter-class>it.tidalwave.netbeans.servlet.NetBeansPlatformDecoratorFilter</filter-class>
        <init-param>
            <param-name>netbeans.filter.delegate</param-name>
            <param-value>org.apache.wicket.protocol.http.WicketFilter</param-value>
        </init-param>
        <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>it.tidalwave.blueocean.webapp.BlueOceanWebApplication</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>WicketFilter</filter-name>
        <url-pattern>/app/*</url-pattern>
    </filter-mapping>

As you can see, the instantiated Filter is the decorated one, while the name of the real Wicket filter is passed as a parameter; applicationClassName is instead a Wicket-specific configuration, and of course it is specified too. It's the name of the class that represents the whole application; it's part of a regular Platform module.

This is how I integrated Milton, a server-side WebDAV implementation, that is based on a servlet front controller:

    <servlet>
        <servlet-name>MiltonServlet</servlet-name>
        <servlet-class>it.tidalwave.netbeans.servlet.NetBeansPlatformDecoratorServlet</servlet-class>
        <init-param>
            <param-name>netbeans.servlet.delegate</param-name>
            <param-value>it.tidalwave.blueocean.milton.MiltonPatchedServlet</param-value>
        </init-param>
        <init-param>
            <param-name>resource.factory.class</param-name>
            <param-value>it.tidalwave.blueocean.milton.MiltonResourceFactory</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>MiltonServlet</servlet-name>
        <url-pattern>/webdav/*</url-pattern>
    </servlet-mapping>

In this case, I had to provide a patched version of the Servlet, since Milton unfortunately uses Class.forName(...) to dynamically instantiate classes, instead of using the current class loader (consider this a bug/missing feature of Milton). resource.factory.class is a configuration parameter of Milton somewhat similar to the applicationClassName of Wicket.

REST is not used in blueOcean yet, but it is already used in the customer's project based on it. This is how the web.xml for it looks like:

    <servlet>
        <servlet-name>JerseyServlet</servlet-name>
        <servlet-class>it.tidalwave.netbeans.servlet.NetBeansPlatformDecoratorServlet</servlet-class>
        <init-param>
            <param-name>netbeans.servlet.delegate</param-name>
            <param-value>com.sun.jersey.spi.container.servlet.ServletContainer</param-value>
        </init-param>
        <init-param>
            <param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
            <param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value>
        </init-param>
        <init-param>
            <param-name>com.sun.jersey.config.property.packages</param-name>
            <param-value>customer.package1;customer.package2</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>JerseyServlet</servlet-name>
        <url-pattern>/rest/*</url-pattern>
    </servlet-mapping>

The ServletContainer in Jersey contains an annotation processor (called ResourceConfig), which scans all the classes in the classpath looking for JSR-311-specific annotations. Unfortunately the default implementation expects the classpath to be the default one for web-applications (WEB-INF/lib etc...) so it doesn't work for the integrated Platform. An alternate annotation processor (PackagesResourceConfig) had to be used, in which you explicitly specify the names of the packages that contains JSR-311 annotations. It's an acceptable trade-off for now; it is clearly possible to write a customized ResourceConfig that scans a Platform classpath - but I need to learn more from Jersey before I'm able to write it.