Question

I don’t want to debate whether or not to undertake the conversion from struts2 -> SpringMVC. I have the best reason to do it. It is what the customer is asking/paying for.

I’ve done struts1 years back and I’ve done SpringMVC. I’m hoping to configure via xml and not use Annotations that much.

My plan is to:

1. Take each struts2 action class, understand what action is taking place and then create a clean API for delegating to the business layer. This step is not required. It is here so we can refactor whatever makes sense.
2. Create a SpringMVC Controller (roughly) for every struts 2 action class.

I know that is just touching the surface of what needs to be done. Anyone have anything else to add?

Thanks in advance,

Andrew

Answer 1

If the struts2 actions were created properly there would be a clean API to the service layer already. Hopefully the Struts2 application is already using Spring DI. Struts2 objects could be reused. But the web layer is relatively thin so it would be best to remove any trace of the struts2 actions to simplify further development, rather than leaving weird artifacts.

There are four main parts that a user of struts is responsible for.

1. The Action Class
2. Struts2 specific tags in the view layer
3. Validation
4. Interceptors

The action class as already mentioned should be quite thin, it’s main purpose is to marshal objects on their way to the view. (To marshal them it will need to set form parameters and validate them). If the objects are acquired from the service layer, then you should be able to mostly cut and paste the logic over into Spring Controllers. If you find logic that should be in the service layer, it should be pushed up.

The tags in the view layer I’m not so sure about. Probably best to replace struts specific tags with jstl tags where possible. Struts2 does not have a huge tag set, and there should be a pretty much one to one mapping between the tags but you’ll need to figure out what that mapping is (and which tag lib is best).

Validation – I don’t know how Spring MVC does validation.

Interceptors address cross cutting concerns, I don’t know how Spring interceptors work. Spring could address the issue of custom interceptors probably with AOP.

All in all, the web tier shouldn’t be very invasive… and I’m not sure what you’ll gain. Be aware that if your current S2 application is not using Spring DI it is quite easy to add, along with AOP and you can even delegate the creation of actions to Spring. As such I would expect very little return in such a conversion. As an alternative, it might just be easier to start building what you need with Spring MVC, and turn the struts2 actions into web services (json is ridiculously easy). Then dismantle them piece wise when you have the time to implement them in Spring MVC. A conversion means understanding two systems and mapping them, it is messy and error prone… this has the same end effect (the removal of the struts2 framework) but would allow for productivity as well.