Afficher la configuration après «Échec de l'initialisation du contexte»
Je cherche maintenant depuis quelques jours la réponse à la question suivante:
J'ai une Spring 2.5application Web et je souhaite afficher un certain écran de configuration si l'initialisation du contexte Spring a échoué. Dans cet écran de configuration, ils peuvent voir pourquoi le serveur ne démarre pas et peut-être apporter des modifications (télécharger un nouveau config.propertiesfichier)
Mais comment puis-je implémenter cela de manière intelligente? Spring a-t-il déjà quelque chose comme ça ou dois-je étendre le ContextLoaderpar exemple?
J'ai essayé quelque chose dans le web.xml comme ceci: mais cela ne semble pas fonctionner:
<error-page>
<error-code>404</error-code>
<location>/public/setup.jsp</location>
</error-page>
Solution:
Je commence avec un web.xml par défaut et une fois la configuration terminée, je remplace le web.xml par la bonne 'application' web.xml. Étant donné que le fichier web.xml est remplacé, les serveurs redémarrent. Cela fonctionne très bien. Merci encore pour vos réponses.
Voici trois idées:
- Modifiez le chargeur de contexte pour intercepter l'exception et ajoutez un servlet / mappage au conteneur qui redirige tous les mappages pertinents vers le servlet chargé dynamiquement. Consultez ce thread de débordement de pile d'instructions sur la création d'un servlet dynamique: Ajoutez dynamiquement un servlet au servletConfig
- Vous pouvez également définir un servlet standard qui gère toutes les demandes et les transmet à la page de configuration. Vous pouvez alors avoir un bean spring qui supprime ce servlet et le mappage du contexte une fois l'initialisation terminée (vous voudrez peut-être mettre ce code dans le hook postInitalize d'un spring bean.)
- Vous pouvez également essayer de créer un écouteur qui vérifie si un contexte d'application valide existe et supprime les sorties de mappage / servlet "par défaut".
Je ne pense pas qu'il existe des mécanismes standard pour ajouter / supprimer des servlets et le mappage du conteneur. Mais il semble que la plupart des conteneurs ont des API qui le font.
Il y a une troisième voie, à laquelle vous faisiez allusion. Ce qui revient à supposer que si une erreur 404 s'est produite, le servlet n'a pas pu démarrer. Si vous empruntez cette voie, je pense que vous rencontrerez le problème que les erreurs 404 peuvent se produire simplement parce que l'utilisateur a touché l'URL.