使用非弹簧Web应用程序可以实现并行Spring-MVC应用程序吗？

Question

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!!

Answer 1

We went through a similar use case some time ago, while migrating moderately large application from EJB 2.1 to Spring. For a great deal of time Spring beans were coexisting with EJBs. We were choosing leafs in the dependency hierarchy first, so that Spring beans depended on EJBs but not the other way around. This was working beautifully, beans were calling EJBs like any other bean thanks to Spring proxies and dependency injection.

In the same application we had both Struts 1 and Wicket for new pages (damn, there were even Wicket iframes inside Struts pages!), we even had legacy JDBC-based persistence solution side by side with JPA. It all worked well.

Things to keep in mind:

1. It's still one application, watch out for back-end caching

2. Treat legacy services like Spring beans. Build some bridges/proxies/adapters, inject legacy services just like you inject other beans. Do not depend on legacy APIs (I imagine some singletons, factories, JNDI lookups)

3. Testing borders between old and new will be hard, prepare for a lot of mocking.

4. Think about web security, can you integrate both "applications" easily?

5. Let's face it, you'll never completely rewrite old code to new technologies. By that time new technologies will become old as well and new developers will come in. But try improving the quality of old code bit-by-bit every time. Refactoring can do miracles!

There is nothing special with configuration. It's a misunderstanding that Spring has to rule your whole application. It can be used as a lightweight, thin add-on, living next to the rest of your application.