Using Spring to manage your Java beans for dependency injection is fairly straightforward, but what do you do when you want Spring to manage beans that were created outside of the Spring container? I encountered this issue on a recent project. The user login credentials were handled by a legacy system and stored in the HTTP session.
Project background
Here’s the background of this particular issue. I created a new web application for a client that followed the design of a typical web application: the data objects were stored in the domain model, the business logic was in a business/service layer, and the data access logic was kept in a data access layer (a typical DAO pattern). The DAO layer and business objects were managed by Spring.
Requirements
We had two security requirements at the DAO layer:
- Check the user’s role. If the user does not have access to this data, throw an exception.
- Check the user’s role. If the user has access, dynamically build a query based on the user’s credentials and only return data the user is authorized to view.
In order to accomplish the security check, we needed the user credentials to be present in the DAO layer. We did not need the user credentials in the business/service layer. The user credentials were stored as a session bean. However, in order to maintain a clear separation of layers, neither the business layer nor the DAO layer had any knowledge of a session. Those layers should not care if this was a web app or a client/server Swing app.
Solution(s)
Our brainstorming session came up with a few options:
- Pass the user credential object as a method parameter from the controller to the business layer, and then from the business layer to the DAO layer.
- Pass the servlet request or session object as a method parameter to the DAO layer. This is even worse than the first idea.
- Change the legacy application that controlled the instantiation of the user credential bean to use Spring, so we could have Spring manage the user credential object. Unfortunately, this was not an option because of the impact it would have on other legacy apps that also used that code.
- Use Spring to create a clone of the user credential bean, and thus let Spring manage that bean for my application. We could use dependency injection to inject the user credential bean into the DAO layer as needed.
- Give up and drink beer.
I chose option 4 - let Spring work its magic. However, there were some problems with this approach that had to be addressed:
- As mentioned earlier, the user credential bean was created by an external application and was not managed by the Spring container.
- When attempting to clone the session bean, that did not work using Apache BeanUtils because the user credential bean did not follow JavaBeans specifications. That meant that reflection would not work because a property called “user” might have a getter or setter called “getUserName”.
How would you have solved these problems? As it turns out, they were minor bumps in the road, and the solution was not as bad as I originally thought. Stay tuned for part 2 - we lay out a plan for coding and start configuring some Spring files.
Stay tuned!