Creating the Spring container

After we've configured the DispatcherServlet, the Spring MVC container must be created. The interface org.springframework.context.ApplicationContext is Spring's more advanced container. The implementation of this object manages other objects of the portal application that will be known later as beans. All beans are injected into this container so that the portal will just "fetch" them once they are needed in several transactions.

There are two ways to create a Spring MVC container and these are:

• XML-based configuration
• JavaConfig-based configuration

Spring container configuration using XML

Using our STS IDE, the ApplicationContext (applicationContext.xml) can be created using the Spring Eclipse plugin. Following is the menu wizard showing the plugin for the Spring Framework module:

On the wizard, click on the Spring Bean Configuration File option which will guide you to the next instruction panel. This is the selection of the XSD namespaces needed by the applicationContext.xml for the Spring components.

After choosing the necessary XSD namespaces needed for bean injections and configurations, the PWP's XML-based container will look like the following configuration:

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:aop="http://www.springframework.org/schema/aop" 
  xmlns:context="http://www.springframework.org/schema/context" 
  xmlns:oxm="http://www.springframework.org/schema/oxm"
  xmlns:tx="http://www.springframework.org/schema/tx" 
  xmlns:mvc="http://www.springframework.org/schema/mvc" 
  xsi:schemaLocation="http://www.springframework.org/schema/aop    http://www.springframework.org/schema/aop/spring-aop-4.1.xsd 
http://www.springframework.org/schema/oxm      http://www.springframework.org/schema/oxm/spring-oxm-4.1.xsd 
http://www.springframework.org/schema/beans      http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 
http://www.springframework.org/schema/tx      http://www.springframework.org/schema/tx/spring-tx-4.1.xsd 
http://www.springframework.org/schema/context      http://www.springframework.org/schema/context/spring-context-4.1.xsd 
http://www.springframework.org/schema/mvc      http://www.springframework.org/schema/mvc/spring-mvc-4.1.xsd"> 
 
    // all beans injected here 
</beans> 

The applicationContext.xml is loaded, accessed, and read by the DispatcherServlet. The convention used so the DispatcherServlet recognizes the container is to name our applicationContext.xml file using the format dispatcherServletName-servlet.xml, wherein the dispatcherServletName is the name indicated by the <servlet-name> tag:

<servlet> 
  <servlet-name>pwp</servlet-name> 
  <servlet-class> 
    org.springframework.web.servlet.DispatcherServlet 
  </servlet-class> 
</servlet> 

Thus, the PWP's applicationContext.xml file is named pwp-servlet.xml. The default filename of an XML-based Spring container must always follow the convention [dispatcher-servlet-name]-servlet.xml.

Spring container configuration using JavaConfig

The other type of implementation of the Spring MVC container is through the JavaConfig classes. In the JavaConfig method, every component tag has its respective annotation equivalent. Following is the equivalent configuration of the preceding XML-based setup.

package org.packt.personal.web.portal.config; 
import org.springframework.context.annotation.Configuration; 
 
@Configuration 
public class PersonalWebPortalConfig {   } 

The @Configuration annotation indicates that this class contains one or more bean methods (usually getters) annotated with @Bean that returns manageable beans of the container. Some references call this class a configurator class.

The two implementations are incomparable, but some projects mix them. XML-based Spring MVC containers become cumbersome when the files get larger, while annotation-based ones can be managed since they are just POJO-based. JavaConfig is a better approach when it comes to using a rapid application development (RAD) strategy. The reason for this is that when the number of components in the project increases, JavaConfig can only just manage the dependencies among beans through autowiring, which the XML cannot impose since the codes are decoupled from the dependency injection process. Debugging is also easy, since bug detection will be done during compilation, unlike in the XML-style where errors will be detected right after the deployment or execution of the application.

On the issue of mixing them, the project must choose which configuration is going to be bootstrapped by the container. If it is the JavaConfig, it must use the @ImportResource to load all the injected beans from the XML:

@Configuration 
@ImportResource("classpath:pws-servlet.xml") 
public class PersonalWebPortalConfig {   } 

If the XML-based configuration is used instead, the XML must use <context:component-scan="org.packt.personal.web.portal"/> to locate the @Configuration class and load all @Bean autowired in it.

In general, the XML-based method is preferred, whenever an Enterprise application is being developed, because XML is still widely used in systems integration techniques. Some legacy systems also preferred the XML-based container.

The PWP project has an XML-based and JavaConfig-based container.