Une application Spring-MVC parallèle est-elle possible avec une application web non-printanière?

Question

J'ai une application Tomcat assez énorme. Très ctitical à l'entreprise (faire de l'argent réel). Mais c'est un code Java hérité. Signification, JSP (avec beaucoup de Javascript, code Java), Servlets (avec des milliers de lignes de code) et ainsi de suite. Nous voulons échapper à ce code minable. Maintenant, une demande est venue pour une autre application (but différent, fonctionnalité différente). Nous en avons besoin dans un autre contexte root/NewApp permet de dire sous la structure du répertoire de l'application héritée. Comme un mini-site. Il aura une URL différente, pourrait même servir quelques hôtes virtuels.

Nous ne voulons pas prolonger le code Legacy. Nous voulons passer à de meilleures technologies et à une meilleure façon de faire les choses. Nous sommes fortement pour le printemps (carreaux, jackson etc. etc.) et tout ce qu'il a à offrir, y compris les portlets. Donc, nous pensons aux possibilités d'introduire DispatcherServlet/ContextLoaderListener/configLocation etc. dans l'application web existante.xml et d'avoir une application printanière côte à côte.

La raison principale est la nouvelle application a de graves dépendances sur les services existants et les bibliothèques.

1. Cette coexistence pacifique est-elle possible?
2. Quels sont les défis auxquels nous pourrions éventuellement faire face?
3. Pouvez-vous s'il vous plaît nous diriger vers des exemples de configurations?

Nous ne pouvons pas les séparer malheureusement. Appréciez votre perspicacité dans ceci.

Merci!

Answer 1

Nous sommes allés dans un cas d'utilisation similaire il y a quelque temps, alors que la migration demande modérément grande d'EJB 2.1 au printemps. Pendant une longue période, les haricots de printemps coexistaient avec les EJB. Nous choisissions d'abord les leafs dans la hiérarchie des dépendances, de sorte que les beans Spring dépendaient des EJB mais pas l'inverse. Cela fonctionnait à merveille, les haricots appelaient les EJB comme n'importe quel autre haricot grâce aux procurations de Spring et à l'injection de dépendances. Dans la même application, nous avions à la fois Struts 1 et Wicket pour les nouvelles pages (sacrément, il y avait même des iframes Wicket dans les pages Struts!), Nous avions même une solution de persistance basée sur JDBC côte à côte avec JPA. Tout a bien fonctionné.

choses à garder à l'esprit:

1. Il est encore une application, attention à la mise en cache back-end

2. services traditionnels Traiter comme les haricots printemps. Construisez des ponts/proxies/adaptateurs, injectez des services existants tout comme vous injectez d'autres beans. Ne pas dépendre des API héritées (j'imagine quelques singletons, usines, recherches JNDI)

3. Tester les frontières entre l'ancien et le nouveau sera difficile, préparez-vous à beaucoup de moqueries.

4. Pensez à la sécurité web, pouvez-vous intégrer les "applications" facilement?

5. visage Let, vous vous repassez jamais complètement ancien code aux nouvelles technologies. À ce moment-là, les nouvelles technologies deviendront anciennes et de nouveaux développeurs viendront. Mais essayez d'améliorer la qualité de l'ancien code bit par bit à chaque fois. Le refactoring peut faire des miracles!

Il n'y a rien de spécial avec la configuration. C'est un malentendu que le printemps doit régner sur l'ensemble de votre demande. Il peut être utilisé comme un ajout léger et léger, vivant à côté du reste de votre application.