traditionelle Projekte konvertieren Boot zu springen, ohne Änderung applicationContext.xml, Dispatcher-servlet.xml & Tomcats context.xml

Question

Der Hintergrund & Anforderungen sind:

1. dort viele alte Projekte, die einen haben application. XML und ein oder mehrere Dispatcher [-XXX] -servlet.xml. Wir hoffen, dass diese Projekte bei der Verwendung von Spring-Boot noch funktionieren können (wir haben ein Deployment-Tool entwickelt, um Spring-Boot-Anwendungen bereitzustellen, aber die alten Projekte werden immer noch manuell bereitgestellt). Aber @SpringBootApplication kann die Kontexte nicht so erstellen, wie sie waren. Und das Umschreiben in Codes eins nach dem anderen kostet zu viel, denke ich.
2. In diesem Projekt verwenden wir eine erweiterte RequestMappingHandlerMapping, so dass wir die native MVC nicht verwenden können.
3. Die Datei context.xml von tomcat, die Jndi-Definitionen enthält, wird von OPs verwaltet. Wir müssen es genauso laden wie Tomcat.
4. i nicht finden können, wo willkommen Datei zu setzen, die
in web.xml gesetzt wurden

ich zur Zeit:

@Configuration 
@ImportResource({"classpath:/applicationContext.xml", "classpath:/dispatcher-servlet.xml"}) 

Those einfache Projekte ohne jndi mit Inbetriebnahme kann.

Aber wie ich verstehe, in diesem Fall sind die ApplicationContext und Dispatcher-Servlet auf der gleichen Ebene (Dispatcher-Servlet sollte das Kind von ApplicationContext, nicht wahr?). Also, ich kann nicht einmal sicherstellen, dass dieses richtig funktioniert.

Answer 1

Wir haben vor ungefähr einem Jahr eine ähnliche Sache gemacht und Ihre Einrichtung war mehr oder weniger die gleiche wie unsere und der Import dieser XML-Dateien hat den Trick gemacht; Das einzige, was wir tun mussten, war sicherzustellen, dass sich unsere Anwendungsklasse in einer anderen Pakethierarchie befand, um konfliktträchtige/doppelte Bean-Definitionen aufgrund ihrer inhärenten @ComponentScan zu vermeiden.

Und mit Dispatcher Servlet und Anwendungskontext im gleichen Kontext wird keine Probleme verursachen - ja, Dispatcher Servlet-Kontext ist in der Regel als separater Kontext definiert und ist ein Kind der breiteren AnwendungContext, aber was die meisten Menschen nicht begreifen Ist diese Trennung nur von Bedeutung, wenn Ihre Anwendung mehr als ein Dispatcher-Servlet haben möchte, was selten der Fall ist, wenn es jemals war.

Im Fall von mehreren Dispatcher-Servlets war es ein Muss, sie mit verschiedenen WebMVC-Konfigurationen zu versehen, und es gab applicationContext, mit dem Sie gemeinsame Beans und Konfigurationen zwischen Ihren Servlet-Kontexten freigeben konnten gleiche Arbeit zweimal.