Common configuration - Java-Springs

Before diving into the integration specifics of each supported web framework, let us first take a look at the Spring configuration that is not specific to any one web framework.

One of the concepts (for want of a better word) espoused by (Spring's) lightweight application model is that of a layered architecture. Remember that in a 'classic' layered architecture, the web layer is but one of many layers; it serves as one of the entry points into a server side application and it delegates to service objects (facades) defined in a service layer to satisfy business specific (and presentation-technology agnostic) use cases. In Spring, these service objects, any other business-specific objects, data access objects, etc. exist in a distinct 'business context', which contains no web or presentation layer objects (presentation objects such as Spring MVC controllers are typically configured in a distinct 'presentation context'). This details how one configures a Spring container (a WebApplicationContext) that contains all of the 'business beans' in one's application.

On to specifics: all that one need do is to declare a Context Loader Listener in the standard Java EE servlet web.xml file of one's web application, and add a context Config Location <context-param/> section (in the same file) that defines which set of Spring XML configuration files to load.

Find below the <listener/> configuration:

<listener-class>org.springframework.web. context.ContextLoaderListener</listener-class>
Find below the <context-param/> configuration:

If you don't specify the contextConfigLocation context parameter, the Context Loader Listener will look for a file called /WEB- INF/ application Context. xml to load. Once the context files are loaded, Spring creates a Web Application Context object based on the bean definitions and stores it in the ServletContext of the web application.

All Java web frameworks are built on top of the Servlet API, and so one can use the following code snippet to get access to this 'business context' Application Context created by the Context Loader Listener.

WebApplicationContext ctx = WebApplicationContextUtils .getWebApplicationContext(servletContext);

The WebApplicationContextUtils class is for convenience, so you don't have to remember the name of the ServletContext attribute. Its getWebApplicationContext() method will return null if an object doesn't exist under the

Web Application Context. ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key. Rather than risk getting Null Pointer Exceptions in your application, it's better to use the

get Required Web Application Context() method. This method throws an exception when the Application Context is missing.

Once you have a reference to the WebApplicationContext, you can retrieve beans by their name or type. Most developers retrieve beans by name and then cast them to one of their implemented interfaces. Fortunately, most of the frame works in this have simpler ways of looking up beans. Not only do they make it easy to get beans from a Spring container, but they also allow you to use dependency injection on their controllers. Each web framework has more detail on its specific integration strategies.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Java-Springs Topics