différents fichiers WAR, ressources partagées

Question

Supposons que vous ayez plusieurs applications qui partagent le même code et la plupart des autres ressources, mais qui ont un aspect différent, certaines étiquettes changent, etc. (pensez à l'image de marque). Si chaque application Web doit aller dans son propre fichier WAR, où mettez-vous les ressources partagées?

J'utilise déjà le classpath pour partager des classes et des fichiers de propriétés. Mais qu'en est-il des fichiers javascript et css? Est le meilleur moyen de créer et de déployer un fichier WAR supplémentaire qui servira ces fichiers partagés à n'importe quelle autre application les requiert? J'ai aussi pensé à un script de construction qui fait un peu de magie et d'une source commune crache les WAR (légèrement) différents, mais je ne l'aime pas parce que cela complique les choses inutilement quand vous avez besoin de construire/tester/exécuter une seule application.

D'autres conseils et astuces seraient appréciés.

Answer 1

Vous pouvez déployer les deux WAR dans le même fichier EAR et mettre des ressources communes dans le fichier EAR. Ensuite, mettez les dépendances appropriées dans le manifeste des applications Web pour lier les fichiers jar dans l'oreille.

Answer 2

Si vous ne voulez pas utiliser la route EAR, utilisez tomcat, etc; il y a quelques autres façons d'atteindre la cohérence que vous voulez. Si vous voulez partager juste js et css, regardez pack:tag. Vous pouvez héberger les fichiers .js et css à partir d'un serveur apache, configurer votre httpd.conf pour que vos webapps puissent les appeler, puis utiliser pack: tag de vos applications wars - DRY et de la compression en une seule étape.

Answer 3

Merci pour les réponses à ce jour, mais j'ai peur d'avoir oublié de mentionner que les WAR seront déployés dans différents environnements complètement isolés les uns des autres. Donc, peut-être avoir une guerre commune déployée à côté de l'application réelle est la seule option. Je pense que je vais aller à ce qui suit:

• WAR1, WAR2 contenant des choses spécifiques à l'application
• CommonWAR containg étoffe commune (sans blague)
• EAR1: WAR1 + CommonWAR, à déployer dans env1
• EAR2: WAR2 + CommonWAR, à déployer dans ENV2

Answer 4

Mise à jour

Oui, encore moi. J'ai en fait changé d'avis (encore :)). Je suis en train actuellement (être ici plus prudent):

• (commune) WAR: contenant l'application, commune (plupart) + quelques trucs spécifiques
• EAR1: CommonWAR + fichier de configuration spécifique pour env1
• EAR2: CommonWAR + fichier de configuration spécifique pour env2

Le fichier de configuration est récupéré par le fichier WAR. Il se trouve sur le chemin de classe EAR et ne contient qu'une seule propriété 'application' avec une valeur. Le GUI unique utilisera alors cette information le cas échéant pour faire la distinction entre les deux applications (config, feuilles de style, ...).Avec ma solution de EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, il était trop difficile ou impossible de rechercher des ressources statiques dans CommonWAR sans utiliser d'URL web (par exemple des images dans des documents PDF générés avec iText).

Answer 5

Une stratégie que j'ai vu utilisé pour de telles configurations de ligne de produits utilise WAR overlays lors de la construction avec maven. Vous définissez un fichier WAR commun qui contient les éléments courants et les superpose aux autres fichiers WAR contenant des éléments spécifiques pour générer des fichiers WAR différents pour chaque application. Cette méthode est probablement plus utile si vous déployez les variantes WAR sur des machines différentes. Mais je ne suis pas sûr de pouvoir le recommander. N'oubliez pas de spécifier la configuration des recouvrements si vous surchargez réellement des éléments, car sinon l'ordre de priorité n'est pas déterministe. Cela pourrait même changer avec une mise à niveau de maven-war-plugin. (Il l'a fait dans notre cas.)

Answer 6

Que diriez-vous de mettre vos css et js dans le classpath et de les servir avec une servlet? Vous pouvez ensuite créer les ressources communes en tant que pot et ce dernier peut même contenir le servlet (répartiteur de ressources si vous le souhaitez) et les fichiers war peuvent contenir le fichier jar dans le dossier WEB-INF/lib.