Using Spring Security 3 with Wicket 6-AuthRoles and JavaConfig and a little Servlet 3

Spring Security is a great framework. It unifies a lot of different authentication mechanisms into a pretty decent package. The only part that wasn’t really up to current Spring-standards was the lack of full java config support. In July they finally released the first fully java config enabled version.

In this blog post I’d like to show how to integrate this new version with Wicket 6-AuthRoles.

The project

I put all the code up on GitHub, clone it and you are ready to go. It shouldn’t be a big surprise that you have to use a Servlet 3 container. I tested the application on Tomcat 7 and Jetty 9, worked without a hitch.

How Spring and Servlet 3 Interact

Servlet 3 provides one of the most fundamental changes. It made web.xml optional. To achieve this the container will scan each war for an implementation of javax.servlet.ServletContainerInitializer to get everything going. Spring provides such a implementation with the SpringServletContainerInitializer. When it is discovered by the container it will then scan the class path for implementations of WebApplicationInitializer. And that’s where we do our stuff.

Servlet 3 Bootstrap

The class AppInitializer contains the whole code required to bootstrap the application. The only really interesting part is how to actually register the Wicket-filter. That cost me some time to figure out but the following snipped does the trick:

        WicketFilter wicketFilter = new WicketFilter(new WicketApplication()) {
            public void init(boolean isServlet, FilterConfig filterConfig) throws ServletException {
                super.init(isServlet, filterConfig);
        FilterRegistration.Dynamic wicketFilterReg = servletContext.addFilter("wicketFilter", wicketFilter);

Auth Roles

Wicket-AuthRoles provide a complete set of annotations to cover all scenarios of authorization. In my demo application I only use @AuthorizeInstantiation.

One important thing to note is that Spring Security prepends ROLE_ to all role names. So instead of writing @AuthorizeInstantiation(Roles.USER) you will have to use @AuthorizeInstantiation(“ROLE_USER”).

Getting AuthRoles to work you need to provide a custom WebSession-implementation:

public class UserAuthenticatedWebSession extends AuthenticatedWebSession {    
    public UserAuthenticatedWebSession(Request request) {

    public boolean authenticate(String username, String password) {
        throw new UnsupportedOperationException("You are supposed to use Spring-Security!!");

    public Roles getRoles() {
        Roles roles = new Roles();
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        for (GrantedAuthority authority : authentication.getAuthorities()) {
        return roles;


The authenticate method is not required as Spring Security is going to take care of that. The only thing we have to do in here is to provide a getRoles-implementation which uses the SecurityContextHolder

Now we have to change the WebApplication to extend AuthenticatedWebApplication and override init, getWebSessionClass and getSignInPageClass:

public void init() {
    getComponentInstantiationListeners().add(new SpringComponentInjector(this));
    getSecuritySettings().setAuthorizationStrategy(new AnnotationsRoleAuthorizationStrategy(this));
    mountPage("/home", HomePage.class);
    mountPage("/login", SignInPage.class);

We also have to specify the /login-mountpoint this should point to a Wicket-page with the following content:

<form method="POST">
    <input type="text" id="username" name="username"/>
    <input type="password" id="password" name="password"/>
    <input type="submit" value="submit"/>

The form-submit will NOT be handled by Wicket but by the Spring Security filter!

Spring Security

The final piece of the puzzle is the Spring Security configuration.

In AppInitializer I added the following code to bootstrap the Spring context and the security filter:

    AnnotationConfigWebApplicationContext root = new AnnotationConfigWebApplicationContext();
    FilterRegistration.Dynamic springSecurityFilterChainReg = servletContext.addFilter("springSecurityFilterChain", DelegatingFilterProxy.class);
    springSecurityFilterChainReg.addMappingForUrlPatterns(EnumSet.of(DispatcherType.ERROR, DispatcherType.REQUEST), false, "/*");
    servletContext.addListener(new ContextLoaderListener(root));

The actual configuration happens in SpringSecurityConfiguration:

public class SpringSecurityConfiguration extends WebSecurityConfigurerAdapter {

    protected void configure(HttpSecurity http) throws Exception {

    protected void registerAuthentication(AuthenticationManagerBuilder auth) throws Exception {

I use configure to tell spring security to allow unrestricted access to favicon.ico. Then I tell it ti restrict access to all other URLs to users with the role USER (reminder: this translates to ROLE_USER when used in AuthRoles-annotations). The last step is to add a custom formLogin to use the mount point from before.

In registerAuthentication I add a simple in-memory-authentication. Here you can now add all the other fancy stuff.

Get it while it’s hot:

Have fun.

Vert.X 2.0.0 in IntelliJ IDEA

Well, that was fast. After posting my last post I saw that vert.x came out last night. Tough luck but sitting on the train I got time enough to provide an update.

Project setup

Follow these to create a basic gradle-project with an example verticle. After doing a gradle clean build idea you can now import the project into Idea.


The examples provided only show how to run this project from the command line. I am a lazy ass and like to run my stuff from the IDE.

To achieve this add a new java-module using File>New Module. Open Open Module Settings, select the newly created module and add contents of the lib-directory from your freshly downloaded vert.x-2.0.0-final-archive in the Dependencies-tab.

Create a new Run-Config and:

  • set Main Class to
  • set Program arguments to runmod com.yourcompany~your-module~1.0 -cp <path-to-your-project>/out/production/<module-name>
  • set Use classpath of module to the module we just created and added the vert.x-libs to

Hit run.


Vert.X in IntelliJ IDEA

Well, that was fast. Outdated within minutes of posting 🙂
This post is for vert.x 1.3.1. 

I just wrote an update on how to do this with vert.x

I took a look at Disruptor back when it was released. It was an interesting piece of software but I never got beyond playing around. Then came Node.js. I have been fighting with myself for quite a while to use it but I am kind of biased when it comes to JavaScript… Well, then came vert.x and I finally had no excuse left to get into this single-threade-thingy-stuff. Playing around with vert.x was quite a fun experience I will write about later. Today I want to show you how to get it running in my favorite IDE.

The Problem

Being polyglot apparently also means to abandon tested deployment strategies. So instead of dumping a JAR/WAR or whatever else into the vert.x-container you will have to do some special magic. And this special magic also involves some tinkering with Idea.

Basic Project

The following (very basic) build.gradle gives you a simple vert.x project.

apply plugin:'java'

configurations {

repositories {
    mavenRepo url: ""
    mavenRepo url: ""
    mavenRepo url: ""

        compile ""
    compile ""
    compile ""

Import it and add a vertical like the following:

package de.codepitbull.vertx;


import java.util.Map;

* @author Jochen Mader
public class HttpVerticle extends Verticle{
public void start() throws Exception {
vertx.createHttpServer().requestHandler(new Handler() {
public void handle(HttpServerRequest req) {
StringBuilder sb = new StringBuilder();
for (Map.Entry<String, String> header : req.headers().entrySet()) {
sb.append(header.getKey()).append(": ").append(header.getValue()).append("\n");
req.response.putHeader("content-type", "text/plain");

And, due to a bug in 1.3.1, you also need to add a to your project with the following content:


To get this whole thing running you will need to download the vert.x tar and untag it to your file system. Next select File>New Module and create a new Java-Module using the wizard. After you are done open Open Module Settings and select your newly created module. Go to the Dependencies-tab and add the content of your vert.x-installations lib-directory. Next add the folder containing Almost there.

Shows the dependency screen in idea with all required deps added.

Start Config

Now that we got our little dummy-project up and going we need to create a start config. So create a new Application-Startconfig. – Set the Main-class to – Set Program arguments to run de.codepitbull.vertx.HttpVerticle -cp where the path is the place where Idea puts your compiled classes from the gradle-project. – Set Use class path of module to the module we just configured. That’s it.

Shows the filled fields as described in the text.

Hit run and go to home sweet home