Basic Spring Interaction with WebLogic Portal

Abstract

BEA WebLogic Portal 8.1 provides a flexible, powerful framework for creating portal interfaces. The Spring Framework is a full-stack Java/Java EE application framework featuring, among other things, an inversion of control (IoC) container, simplified POJO development, and AOP functionality. The goal of this tutorial is to demonstrate how basic Spring functionality can be leveraged in a WebLogic Portal application. One use case focuses on page flows and Spring while the other use case focuses on backing files and Spring. In each use case, we show how the same Portal/portlet code is used to interact with different implementation objects accessed using the Spring framework.

Introduction

BEA WebLogic Portal provides enterprise portal infrastructure for streamlined portal development. This includes a graphical environment for developing portals as well as browser-based assembly tools. The version used in this exercise is BEA WebLogic Portal 8.1 with Service Pack 6.

The Spring Framework encourages a layered architecture that provides centralized configuration and wiring of application objects through its inversion of control container. While Spring provides a variety of abstraction layers and integrations, this example demonstrates only the core features of Spring. The version used is Spring Framework 1.2.8. For a basic introduction to Spring, see Better J2EEing with Spring (Dev2Dev, July 2005).

Two use cases are considered in this article, both focusing on the core functionality provided by Spring. One case demonstrates using Spring features in WebLogic Portal page flows, while the other demonstrates using Spring features in WebLogic Portal backing files.

This article looks at each use case and includes a description of how to implement them.

Demonstration Application Architecture

A demonstration application accompanies this article and consists of a one-page portal created using BEA WebLogic Workshop. It is a file-based portal with four portlets in a two-column layout, forming a simple matrix as shown in Figure 1.

Figure 1. Portlet matrix with two types of portlets, declaratively configured in two different ways

Two of the portlets are instances of a page flow portlet while the other two portlets are instances that use a Java backing file. Each portlet has its own portlet preference of BeanName. The value of this preference is the name of the Spring bean, as defined in the Spring configuration file applicationContext.xml. One of the Spring beans is implemented as a simple Java class that stores and retrieves employee records using a Hashtable. The other Spring bean is implemented in a Java class that stores and retrieves employee records using JDBC to access the default, installed database.

The four portlet instances form a simple matrix. One page flow portlet uses the Hashtable bean while the other page flow portlet uses the JDBC bean. Similarly, one backing file portlet uses the Hashtable bean while the other backing file portlet uses the JDBC bean. The two page flow portlets are instances of the same portlet implementation. The only difference is the value of the portlet preference that refers to either the Hashtable or the JDBC bean. Similarly, the same code is used in the two backing file portlets.

The cases shown here take advantage of the same Spring application context, which gets created using a Spring ContextLoaderListener entry in web.xml. This entry causes Spring to make the application context singleton available. The web.xml file is located under the application's WEB-INF directory and needs an additional listener to initialize the context.

This is the additional listener in web.xml:

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

By default, Spring looks for an application context configuration file named applicationContext.xml located in that same WEB-INF directory. For the demonstration application, the applicationContext.xml file defines two employee service beans containing references to two employee beans each. The definitions of the two employee service beans are the same, except for the employee service class name. One bean refers to the EmployeeServiceHashtable class while the other refers to the EmployeeServiceJDBC class. Both of these classes implement the EmployeeService interface.