【问题标题】：Is a parallel Spring-MVC application possible with a non-spring web app?非 Spring Web 应用程序是否可以使用并行 Spring-MVC 应用程序？
【发布时间】：2012-10-14 16:32:52
【问题描述】：
我有一个非常庞大的 Tomcat 应用程序。对业务非常重要（真正赚钱）。但它是遗留的 Java 代码。含义，JSP（带有大量的 Javascript、Java 代码）、Servlets（带有数千行代码）等等。我们想摆脱这个糟糕的代码。现在已经有另一个应用程序的请求（不同的目的，不同的功能）。我们需要它在另一个上下文根 /NewApp 让我们说在遗留应用程序目录结构下。就像一个迷你网站。它将有一个不同的 URL，甚至可以为一些虚拟主机提供服务。
我们不想扩展旧代码。我们希望转向更好的技术和更好的做事方式。我们强烈支持 Spring（tiles、jackson 等）以及它必须提供的所有东西，包括 portlet。因此，我们正在考虑将 DispatcherServlet/ContextLoaderListener/configLocation 等引入遗留应用程序 web.xml 并并排拥有一个 spring 应用程序的可能性。
主要原因是新应用严重依赖遗留服务和库。
- 这种和平共处可能吗？
- 我们可能面临哪些挑战？
- 能否请您指出任何示例配置？
很遗憾，我们无法将它们分开。感谢您对此的洞察力。
谢谢！！
【问题讨论】：
标签：
java
spring
tomcat
spring-mvc
【解决方案1】：
前段时间，我们在将中等规模的应用程序从 EJB 2.1 迁移到 Spring 时经历了一个类似的用例。很长一段时间，Spring bean 与 EJB 共存。我们首先在依赖层次结构中选择叶子，因此 Spring bean 依赖于 EJB，而不是相反。这工作得很好，由于 Spring 代理和依赖注入，bean 像任何其他 bean 一样调用 EJB。
在同一个应用程序中，我们为新页面同时使用了 Struts 1 和 Wicket（该死，Struts 页面中甚至还有 Wicket iframe！），我们甚至还有基于 JDBC 的遗留持久性解决方案和 JPA。一切都很好。
注意事项：
它仍然是一个应用程序，注意后端缓存
将遗留服务视为 Spring bean。构建一些桥接器/代理/适配器，像注入其他 bean 一样注入遗留服务。不要依赖遗留 API（我想象一些单例、工厂、JNDI 查找）
测试新旧边界会很困难，准备好进行大量模拟。
想想网络安全，你能轻松集成这两个“应用程序”吗？
让我们面对现实吧，您永远无法将旧代码完全重写为新技术。到那个时候新技术也会变老，新的开发者也会进来。但是每次都要尝试一点一点地提高旧代码的质量。重构可以创造奇迹！
配置没有什么特别之处。 Spring 必须统治你的整个应用程序是一种误解。它可以用作轻量级、轻薄的插件，与您的应用程序的其余部分相邻。