Portlet filters and Spring tutorial
Working with a complex product like WebSphere, it helps to integrate a lightweight framework. This portal and Spring tutorial demonstrates how to use portal filters with Spring.
I love the power and simplicity of the Spring Framework, and given the fact that portal servers like WebSphere are often seen as being overly complicated and cumbersome, integrating a simple framework like Spring into the often intimidating portlet API can both simplify and accelerate development. There is also a previous Spring tutorial that demonstrated how the popular framework can integrate into the portlet API.
Updated Spring inversion of control (IoC) tutorials and dependency injection examples
TheServerSide has been updating its resources in terms of the Spring framework, Java EE contexts and various different approaches to inversion of control (IoC) and dependency injection (DI). Check out these newer resources on the topic:
- Inversion of control explained fast with a Spring IoC example
- Spring MVC Java web development with Spring Boot
- Drawbacks to IoC and how to solve inversion of control problems
- Spring IoC vs. Google Guice's inversion of control approach
- Getting started with Google Guice
- Getting started with the Spring IoC container
- The beauty of Spring without XML: Annotation based IoC
In this portlet development and Spring tutorial, I want go beyond some of the simple basics and share the successful approach I took to a problem that was encountered while implementing a WebSphere Portal solution for one of my industrial clients.
The requirements
I love the power and simplicity of the Spring Framework.
We needed to be able to share and consume user profile information. The user details would be used to personalize content and improve the overall customer experience. This remains a common use case for many modern WebSphere Portal implementations. Luckily, WebSphere Portal offers out-of-the-box extensions, namely their Login, Logout and Session filters.
Conceptually, the solution is simple:
- The user logs in.
- The Portal Login Filter looks up resources from external sources (i.e., DB, REST APIs and others).
- The user profile is created.
- We add the user profile to the WebSphere DynaCache.
- The user profile is consumed by portlets, web content management (WCM) components and themes as required.
I had already developed the DynaCache and JPA database components for use with the portlet. Next, I hoped I could simply create a WebSphere Portal Login Filter and plug in my pre-existing cache and database beans.
The problem
The real problem is that WebSphere is responsible for the instantiation and runtime of the portal filters and can't be easily extended to leverage Spring annotations. I needed to find a way to continue to leverage Spring and reuse the existing annotated code.
The solution
I reached out to a colleague of mine who I respect and admire very much. Our discussions led to a deeper understanding of how Spring Inversion of Control actually works. Based on this new understanding, I was able to develop the following solution.
First, I defined all my beans in the appContext.xml configuration file. Next, I created a Factory bean where I defined the autowire annotations defined in the appContext.xml. Finally, I created an ApplicationContext instance in my portlet filter to the bean factory, and to access all of the beans I needed in the filter, I did the following:
- Created a Spring configuration file -- appContext.xml -- and placed it in the classpath of the project.
- That is, in a Maven project, add it to the /src/main/resources source folder.
- That is, in a Maven project, add it to the /src/main/resources source folder.
- Defined all of the beans and made sure to add unique identifiers.
- Created the LeoneBeanFactory class and autowired the beans.
- Added the following code to the Login Filter to create an ApplicationContext instance and instantiated the Bean Factory.
First we defined the ApplicationContext and loaded in the appContext.xml file from the classpath. The appContext.xml is hard-coded in the above example to improve readability.
When the context.getBean() method is called, Spring performs all its magic in the background and autowires all the beans.
- In the portlet filter, leveraged the beans from the Bean Factory.
Summary
The solution presented in this portal and Spring tutorial can be used beyond the usage described WebSphere Filter example. It's meant to illustrate a way to use Spring when you don't have control over the runtime environment, but still want to reuse your existing Spring code. It took me an inordinate amount of time to find this seemingly simple solution. I hope, at the very least, that I've saved you a several frustrated hours of "googloutioning" (aka using googling to find a solution).
What is your experience integrating Spring with portal? Let us know.
Next Steps:
Five portlet development tips
Avoid PortletPreferences for performance
Respecting the servlet API with portlet development