Portlet filters and Spring tutorial

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:

1. The user logs in.
   
   
2. The Portal Login Filter looks up resources from external sources (i.e., DB, REST APIs and others).
   
   
3. The user profile is created.
   
   
4. We add the user profile to the WebSphere DynaCache.
   
   
5. 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:

1. 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.
     
     
2. Defined all of the beans and made sure to add unique identifiers.
   
   
3. Created the LeoneBeanFactory class and autowired the beans.

4. 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.

5. 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