Is a parallel Spring-MVC application possible with a non-spring web app?

[avaj eikunj]

Dear Spring Gurus,

I have a Tomcat application pretty huge. Very ctitical to the business (real money making). But it is legacy Java code. Meaning, JSP (with a lot of Javascript, Java code), Servlets (with thousands of lines of code) and so on. We want to get away from this crappy code. Now a request has come for another application (different purpose, different functionality). We need it at another context root /NewApp lets say under the legacy application directory structure. Like a mini-site. It will have a different URL, could even be serving a few virtual hosts.

We dont want to extend the Legacy code. We want to move to better technologies and better way of doing things. We are strongly for Spring (tiles, jackson etc. etc.) and all the things it has to offer including portlets. So, we are thinking of possibilities of bringing in DispatcherServlet/ContextLoaderListener/configLocation etc into the legacy app web.xml and have a spring app side by side.

The main reason is the new app has serious dependencies on the legacy services and libraries.

1. Is this peaceful coexistance possible?
2. What are the challenges that we could possibly face?
3. Can you please point us to any example configurations?

We cant separate them out unfortunately. Appreciate your insight into this.

Thank you!!

[Jayesh A Lalwani]

We did integrate a Struts application with a Spring MVC application. However, you have to be careful. Technically, SPring MVC can coexist with other servlets (home grown or Struts). You just map the URL to the DispatcherSevlet. However, remember that when you bring Spring MVC into your webapp, you are bringing in a lot of other 3rd party jars that Spring depends on. You might be using the older version of that jar in your existing code. This means that you might have to force an upgrade of a jar on the old code. Usually, moving to a newer version of most popular open source projects (like Apache Commons) is not a problem, but it's a good idea to test it

What we ended up doing is before writing even a line of Spring MVC code, we first identified the conflicts, upgraded the jars, and ran regression tests on the existing code. When everything ran fine, we started implementing the new functionality using Spring MVC