Other Web Frameworks

This chapter details Spring’s integration with third-party web frameworks.

One of the core value propositions of the Spring Framework is that of enabling choice. In a general sense, Spring does not force you to use or buy into any particular architecture, technology, or methodology (although it certainly recommends some over others). This freedom to pick and choose the architecture, technology, or methodology that is most relevant to a developer and their development team is arguably most evident in the web area, where Spring provides its own web frameworks (Spring MVC and Spring WebFlux) while, at the same time, supporting integration with a number of popular third-party web frameworks.

Common Configuration

Before diving into the integration specifics of each supported web framework, let us first take a look at common Spring 설정 that is not specific to any one web framework. (This section is equally applicable to Spring’s own web framework variants.)

One of the concepts (for want of a better word) espoused by Spring’s lightweight 애플리케이션 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 서버-side 애플리케이션, and it delegates to 서비스 객체 (facades) that are defined in a 서비스 layer to satisfy business-specific (and presentation-technology agnostic) use cases.

In Spring, these 서비스 객체, any other business-specific 객체, data-access 객체, and others exist in a distinct "business context", which contains no web or presentation layer 객체 (presentation 객체, such as Spring MVC controllers, are typically configured in a distinct "presentation context"). This section details how you can configure a Spring 컨테이너 (a WebApplicationContext) that contains all of the 'business beans' in your 애플리케이션.

Moving on to specifics, all you need to do is declare a ContextLoaderListener in the standard Jakarta EE 서블릿 web.xml file of your web 애플리케이션 and add a contextConfigLocation <context-param/> section (in the same file) that defines which set of Spring XML 설정 files to load.

Consider the following <listener/> 설정:

1<listener>
2	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
3</listener>

Further consider the following <context-param/> 설정:

1<context-param>
2	<param-name>contextConfigLocation</param-name>
3	<param-value>/WEB-INF/applicationContext*.xml</param-value>
4</context-param>

If you do not specify the contextConfigLocation context parameter, the ContextLoaderListener looks for a file called /WEB-INF/applicationContext.xml to load. Once the context files are loaded, Spring creates a WebApplicationContext 객체 based on the bean definitions and stores it in the ServletContext of the web 애플리케이션.

All Java web frameworks are built on top of the Servlet API, so you can use the following code snippet to get access to this "business context" ApplicationContext created by the ContextLoaderListener.

The following example shows how to get the WebApplicationContext:

1WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);

The WebApplicationContextUtils class is for convenience, so you need not remember the name of the ServletContext attribute. Its getWebApplicationContext() 메서드 returns null if an 객체 does not exist under the WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE key. Rather than risk getting NullPointerExceptions in your 애플리케이션, it is better to use the getRequiredWebApplicationContext() 메서드. This 메서드 throws an 예외 when the ApplicationContext 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 인터페이스.

Fortunately, most of the frameworks in this section have simpler ways of looking up beans. Not only do they make it easy to get beans from a Spring 컨테이너, but they also let you use dependency injection on their controllers. Each web framework section has more detail on its specific integration strategies.

JSF

JavaServer Faces (JSF) is the JCP’s standard 컴포넌트 기반, 이벤트 기반 web user 인터페이스 framework. It is an official part of the Jakarta EE umbrella but also individually usable, for example, through embedding Mojarra or MyFaces within Tomcat.

Please note that recent versions of JSF became closely tied to CDI infrastructure in 애플리케이션 서버, with some new JSF functionality only working in such an environment. Spring’s JSF support is not actively evolved anymore and primarily exists for migration purposes when modernizing older JSF-based 애플리케이션.

The key element in Spring’s JSF integration is the JSF ELResolver mechanism.

Spring Bean Resolver

SpringBeanFacesELResolver is a JSF compliant ELResolver 구현, integrating with the standard Unified EL as used by JSF and JSP. It delegates to Spring’s "business context" WebApplicationContext first and then to the default resolver of the underlying JSF 구현.

Configuration-wise, you can define SpringBeanFacesELResolver in your JSF faces-context.xml file, as the following example shows:

1<faces-config>
2	<application>
3		<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
4		...
5	</application>
6</faces-config>

Using FacesContextUtils

A custom ELResolver works well when mapping your properties to beans in faces-config.xml, but, at times, you may need to explicitly grab a bean. The FacesContextUtils class makes this easy. It is similar to WebApplicationContextUtils, except that it takes a FacesContext parameter rather than a ServletContext parameter.

The following example shows how to use FacesContextUtils:

1ApplicationContext ctx = FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance());

Apache Struts

Invented by Craig McClanahan, Struts is an open-source project hosted by the Apache Software Foundation. Struts 1.x greatly simplified the JSP/Servlet programming paradigm and won over many developers who were using proprietary frameworks. It simplified the programming model; it was open source; and it had a large community, which let the project grow and become popular among Java web developers.

As a successor to the original Struts 1.x, check out Struts 2.x or more recent versions as well as the Struts-provided Spring Plugin for built-in Spring integration.

Apache Tapestry

Tapestry is a "Component oriented framework for creating dynamic, robust, highly scalable web 애플리케이션 in Java."

While Spring has its own powerful web layer, there are a number of unique advantages to building an enterprise Java 애플리케이션 by using a combination of Tapestry for the web user 인터페이스 and the Spring 컨테이너 for the lower layers.

For more information, see Tapestry’s dedicated integration module for Spring.

Further Resources

The following links go to further resources about the various web frameworks described in this chapter.

• The JSF homepage
• The Struts homepage
• The Tapestry homepage