J'ai quatre projets différents, et j'utilise Weblogic pour déployer mes projets. Il existe plusieurs bibliothèques (fichiers jar) communes à tous les projets. Actuellement, chacun de mes projets ont le répertoire lib et ont presque le même ensemble de bibliothèques. Maintenant, est-il possible d'avoir ce répertoire lib à l'extérieur des fichiers WAR et d'y accéder.Comment utiliser les bibliothèques communes pour plusieurs projets Web Java
Résistez à la tentation de placer les fichiers jar dans le dossier "shared" de votre conteneur. Il est préférable de conserver les fichiers jar où ils sont maintenant. Cela peut sembler une bonne idée d'utiliser un dossier partagé maintenant, mais à l'avenir, vous devrez peut-être déployer une application qui nécessite une bibliothèque partagée, mais une version différente. Cela dit, je n'ai aucune expérience avec WebLogic. Dans Tomcat, il existe un dossier partagé avec des bibliothèques communes à toutes les applications déployées. Ce n'est pas une bonne idée de l'utiliser. Si WebLogic peut être configuré pour utiliser un dossier partagé par un ensemble d'applications (et non pour toutes les applications déployées), vous pouvez le faire.
Eh bien tout d'abord vous pouvez mettre vos libs tous au même endroit et avoir votre processus de construction d'importer ceux nécessaires.
A pour déployer le nouveau Weblogic 10 a un dossier lib dans chaque domaine où vous pouvez mettre des bibliothèques partagées. Je ne pense pas que ce soit possible avant Weblogic 10
Il existe un support de bibliothèque partagée dans la version 9: http://e-docs.bea.com/wls/docs92/programming/libraries.html – McDowell
J'utilise actuellement une autre approche.
Everytime, la copie de travail local est mis à jour, les sont mis à jour externals, vous avez juste besoin de s'engager dans le dossier central et il est automatiquement distribué à tous les projets.
Voulez-vous faire ceci? À moins que vous ne soyez bloqué pour l'espace de déploiement, je le conseillerais (peut-être) contre cela.
Pourquoi? Pour le moment, vous avez 4 solutions qui fonctionnent sur ces bibliothèques. Si vous devez mettre à niveau l'une des bibliothèques (par exemple, si vous découvrez un bogue, ou si vous avez besoin d'une nouvelle fonctionnalité), vous devrez tester la compatibilité et la fonctionnalité pour les quatre solutions. Si chaque solution a son propre ensemble de bibliothèques, elles sont en sandbox et vous n'avez pas besoin de les déplacer toutes les quatre. Notez que tout ceci dépend de la simplicité de test de régression de vos solutions. Vous pouvez le trouver facile, auquel cas l'utilisation du même ensemble de bibliothèques est possible.
Ne faites pas cela.
L'idée générale des fichiers WAR est qu'ils sont des unités autonomes. Cela rend le déploiement beaucoup plus facile. En plus des conflits de version possibles que d'autres ont signalés, mettre des fichiers jar dans/shared peut avoir des conséquences très imbriquées pour la visibilité de la classe. Ils seront sur un chargeur de classe distinct et ne pourront pas voir les classes dans le fichier WAR. Si vous utilisez des bibliothèques qui s'appuient sur Class.forName() pour fonctionner (et il y en a beaucoup), cela pourrait être très douloureux.
Si vous ne pouvez vraiment pas vous permettre l'espace disque supplémentaire et la mémoire regardez OSGi ou Spring DM.Ils ont résolu ce problème, mais au prix d'une complexité accrue.
Placez tous les fichiers jar partagés dans le dossier \ lib commun de weblogic. common \ lib est accessible à toutes les applications déployées.
Vous pouvez placer les bocaux dans leur propre fichier oreille et le déployer en tant que bibliothèque partagée.
Vous pouvez également mettre les guerres dans l'oreille et ajouter les jars partagés à APP-INF/lib. C'est une extension Weblogic de J2EE, donc cela ne fonctionnera pas sur d'autres serveurs.
Bon conseil! Il y a très peu de frais généraux pour avoir une copie supplémentaire d'un fichier jar, alors que devoir fudger deux versions d'une bibliothèque commune au même endroit ou forcer toutes vos applications à passer à une nouvelle version au même moment est une vraie douleur . –
En fait, après la compilation de la taille du projet est d'environ 1,5 Mo (sans librairies), et 20 Mo (avec libs) –
Vous pouvez utiliser le dossier partagé dans votre machine de développement afin de rendre le déploiement plus rapide. Dans un environnement de production, cela n'a pas beaucoup d'importance, alors préférez un gros fichier WAR avec tous les jars à l'intérieur. Si vous le faites, vous devez faire des tests deux fois (à la fois pour les petites et grandes WAR). – kgiannakakis