Upgrading large application from spring 3.0.x to 4.1.x - What best practices / procedures should I follow?

Question

I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.

I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.

What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)

The system:

• Java 6 - jax-b/-p/-ws/, Apache Commons,

• Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi

• Hibernate 3.5

• Tomcat 6

• 0 unit tests or automated testing of any kind.

• Maven dependency management and build automation.

• Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.

• Hundreds of views, scores of controllers.

Steps I've taken so far:

• Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)

• I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.

My questions:

• What steps/procedures are considered 'best practice' in these for a job like this?

• Does anything jump out at you as a 'gotcha' for a job like this?

Answer 1

Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:

1. Requirements, requirements, requirements

   Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.

   If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.

   It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.

2. Spring projects have evolved a lot. Budget for learning time.

   This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:

   • Java 8 features
   • JavaConfig (as opposed to xml configuration)
   • Acegi is now Spring Security
   • Spring projects typically use Spring Boot
   • Switch from Maven to Gradle for building projects
   • Full CI using Jenkins (or other CI tools)
   • Unit and integration testing have moved on to using annotations (and mock frameworks)

Answer 2

Well, it is not easy to answer you question since there are many things to be taken into account.

First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.

I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries. Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts. Take also a look to the dependency updates section.

Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).

I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.

Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).

It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.

You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements. A little resume of new features is the following:

• Removed Deprecated Packages and Methods
• Java 8 Support
• Java EE 6 and 7 become the baseline
• Groovy Bean Definition DSL
• Core Container Improvements
• General Web Improvements
• WebSocket, SockJS, and STOMP Messaging
• Testing Improvements with extreme use of annotations

Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.

Answer 3

You have to have answer to the following before you proceed.

Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?

OR

You really want to get the most out of Spring 4.x ?

Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.

So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.

You may redesign the whole app in Spring 4 as if it is a new application.

Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.