I am currently working on a project for Packt Publishing to update Spring Security 2nd Edition, to the 3rd edition.

I wanted to detail some of the progress and in Chapter 2, we describe the Servlet 3.0+ initialization process in Spring Mvc:

ContextLoaderListener

The first step of updating the web.xml file is to remove it and replace it with a javax.servlet.ServletContainerInitializer, which is the preferred approach to Servlet 3.0+ initialization. Spring Mvc provides o.s.w.WebApplicationInitializer interface leverage this mechanism. In Spring Mvc the preferred approach is to extend o.s.w.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer which implements WebApplicationInitializer.

WebApplicationInitializer is polymorphically a o.s.w.context.AbstractContextLoaderInitializer and uses the abstract createRootApplicationContext() method to create a root ApplicationContext and delegates it to ContextLoaderListener which then is being registered in the ServletContext instance as seen in the following code snippet:

    @Override
    public void addResourceHandlers(final ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/resources/**")
                .addResourceLocations("/resources/")
                .setCachePeriod(31_556_926)
        ;

        // Add WebJars for Bootstrap & jQuery
        if (!registry.hasMappingForPattern("/webjars/**")) {
            registry.addResourceHandler("/webjars/**").addResourceLocations(
                    "classpath:/META-INF/resources/webjars/");
        }

        if (!registry.hasMappingForPattern("/**")) {
            registry.addResourceHandler("/**").addResourceLocations(
                    CLASSPATH_RESOURCE_LOCATIONS);

        }
    }

 

The updated configuration will now load SecurityConfig.class from the classpath of the WAR.

ContextLoaderListener versus DispatcherServlet

The o.s.web.servlet.DispatcherServlet specifies configuration classes to be loaded of its own using the getServletConfigClasses() method:

DispatcherServlet creates o.s.context.ApplicationContext, which is a child of the root ApplicationContext interface. Typically, Spring MVC-specific components are initialized in the ApplicationContext interface of DispatcherServlet, while the rest are loaded by ContextLoaderListener. It is important to know that beans in a child ApplicationContext (such as those created by DispatcherServlet) can reference beans of its parent ApplicationContext (such as those created by ContextLoaderListener). However, the parent ApplicationContext cannot refer to beans of the child ApplicationContext. This is illustrated in the following diagram where childBean can refer to rootBean, but rootBean cannot refer to childBean.

 

As with most usage of Spring Security, we do not need Spring Security to refer to any of the MVC-declared beans. Therefore, we have decided to have ContextLoaderListener initialize all of Spring Security’s configuration.

I wanted to visually describe this Object relationship to ensure I have a full understanding of this process:

Reference:

Spring Security 2nd Edition (Robert Winch)

END

Mick Knutson

Java, JavaEE, J2EE, WebLogic, WebSphere, JBoss, Tomcat, Oracle, Spring, Maven, Architecture, Design, Mentoring, Instructor and Agile Consulting. http://www.baselogic.com/blog/resume

View all posts

Java / JavaEE / SpringFramework Channel

BLiNC Supporters

BLiNC Adsense