Filter (Quick)
Filters are an important part of your web application. In classical applications you register your filters using the web.xml. In an OSGi engine services could come and go as they like. Therefore we need different approaches. For pax-wicket you have two options. Either use the namespaces from spring/blueprint or register them manually.
Be careful! Before PAX-WICKET 2.0.0 the filter does not implement the correct filter lifecycle right now, but rather creates a new filter for each request and neither calls the init nor the destroy methods.
With PAX-WICKET 2.0.0 the correct lifecycle is available by default. If you like to activate the previous behavior again add a "pax.wicket.filter.maintainlifecycle=false" property to your filter.
Filters are attached to the right application by the pax.wicket.applicationname defined for the application. As you can see in all the following examples we always bind a filter to a specific application using the pax.wicket.applicationname property.
Expect that you've a simple filter (or a more complex one e.g. from Jetty or somewhere else).
public class IAmASysoutFilter implements Filter {
public void init(FilterConfig filterConfig) throws ServletException {
System.out.println("Init filter");
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException,
ServletException {
System.out.println("filter...filter...fileter....");
}
public void destroy() {
System.out.println("Destroy filter");
}
}
Register a filter using the Pax-Wicket namespace
All you have to do is to register your class. What you see in addition here is a priority. That one is required to execute filters in a specific order. The filters with the highest priority will be executed first then the lower ones. Of cause the priority can change at any time.
<wicket:filter id="sysoutFilter" filterClass="org.ops4j.pax.wicket.samples.blueprint.filter.internal.IAmASysoutFilter" priority="1"
applicationName="blueprint.filter.paxwicket" />
Register a filter manually
To be able to register a filter manually you need to provide a filter factory. For our IAmASysoutFilter such a factory could look like the following part. Please notice that the priority in this case is set in the factory instead of in the registry. This has the advantage that it could be changed quite easily from case to case dependent on various outer conditions.
public class SampleFilterFactory implements FilterFactory {
public int compareTo(FilterFactory o) {
if (o.getPriority() < 1) {
return 1;
}
if (o.getPriority() > 1) {
return -1;
}
return 0;
}
public Integer getPriority() {
return 1;
}
public String getApplicationName() {
return "blueprint.filter.paxwicket";
}
public Filter createFilter(ConfigurableFilterConfig filterConfig) {
return new IAmASysoutFilter();
}
}
After that we'll simply have to register the service in the OSGi registry:
<service interface="org.ops4j.pax.wicket.api.FilterFactory">
<service-properties>
<entry key="pax.wicket.applicationname" value="blueprint.filter.default" />
</service-properties>
<bean class="org.ops4j.pax.wicket.samples.blueprint.filter.internal.SampleFilterFactory" />
</service>
SuperFilter
A WebApplicationFactory can be annotated with this to provide a hint that the supplied "SuperFilter" must be used with this application. A {@link SuperFilter} is required to allow specifying a global {@link Filter} that is always called before any other custom filters and will be initialized before the {@link WebApplication} is started, thus it is tied to the lifecycle of the underlying Servlet like in a classical WebApplication environment. This allows to enable special features of Wicket like Atmosphere integration, Native Websockets or Shiro <br><b>There is one special case</b> when the filter (an no more than one is allowed per application!) extends {@link WicketFilter} it is used as the base class of PAX Wickets Wicket integration (this is needed for NativeWebsockets and maybe future Wicket extensions).
Full sample
The full sample showing the code above is located here.