Extension des applications Web Java avec des plugins

Question

J'ai cette application Web qui est devenue un gâchis ingérable.

Je souhaite le scinder en un "cadre" commun. une partie (qui inclut toujours des éléments Web tels que des pages et des images) et plusieurs modules qui ajoutent des fonctionnalités et des écrans supplémentaires. Je souhaite que ce refactoring soit également utile en tant que système de plug-in pour les extensions tierces.

Tous les modules doivent constituer une unité de déploiement séparée, idéalement un fichier war ou jar.

J'ai essayé de créer plusieurs fichiers war normaux, mais Tomcat conserve (conformément à la spécification du servlet) ces fichiers war complètement séparés les uns des autres, de sorte qu'ils ne puissent pas partager leurs classes, par exemple.

J'ai besoin de plugins pour pouvoir voir le " main " classpath.

Je dois utiliser l'application principale pour pouvoir contrôler les plugins, par exemple pour pouvoir les lister et définir leur configuration.

Je souhaite maintenir une séparation complète entre les plugins eux-mêmes (à moins qu'ils ne spécifient des dépendances) et toute autre application Web non liée pouvant s'exécuter sur le même Tomcat.

Je souhaiterais qu’ils soient ancrés sous le "principal" préfixe de l'URL de l'application, mais cela n'est pas nécessaire.

Je voudrais utiliser Tomcat (les modifications architecturales importantes doivent être coordonnées avec trop de personnes), mais aussi entendre parler d’une solution propre dans le monde EJB ou OSGi, le cas échéant.

Answer 1

J'ai bricolé l'idée d'utiliser OSGi pour résoudre le même problème que vous décrivez. En particulier, je cherche à utiliser les Spring Dynamic Modules .

Answer 2

Consultez les portlets Java - http://developers.sun.com / portalserver / reference / techart / jsr168 / - en un mot, une spécification qui permet l’interopérabilité entre des applications Web j2ee autonomes par ailleurs

Modifier J'ai oublié de mentionner que les portlets sont pratiquement indépendants du cadre. Vous pouvez donc utiliser Spring pour l'application mère et les développeurs peuvent utiliser ce qu'ils veulent sur leurs portlets.

Answer 3

Avez-vous envisagé d'utiliser maven pour séparer vos projets, puis le faire résoudre les dépendances entre les fichiers WAR et les fichiers JAR? Vous vous retrouverez avec une duplication des bibliothèques entre les WAR, mais seulement là où cela est nécessaire (et cela ne devrait pas poser de problème, sauf si vous vous amusez de façon amusante avec un chargeur de classe).

Tomcat vous permet également de configurer des applications inter-contextes si vous avez besoin de passer d'un WAR à un autre de manière relativement transparente ...

Si vous souhaitez conserver les éléments sous la même application Web (par exemple, ROOT), vous pouvez créer une application Web proxy qui est ensuite transmise en arrière-plan à l’autre application Web appropriée afin que l’utilisateur la rende relativement transparente.

Answer 4

Votre principal problème va être centré sur les actifs physiques et statiques du système - le reste consiste simplement, efficacement, en pots.

Les fichiers WAR sont séparés, dans Tomcat, avec des chargeurs de classes distincts, mais également au niveau de la session (chaque fichier WAR est une application Web individuelle et possède son propre état de session).

Dans Glassfish, si les fichiers WAR étaient regroupés dans un fichier EAR, ils se partageraient les chargeurs de classe (GF utilise un espace de chargeur de classe plat dans les fichiers EAR), mais conservait toujours un état de session distinct.

Par ailleurs, je ne suis pas sûr que vous puissiez faire un "transfert". vers un autre WAR du serveur. Le problème est que les transferts utilisent une URL relative à la racine de l'application Web et que chaque application Web a sa propre racine, vous ne pouvez donc tout simplement pas y accéder à partir de cet endroit. Vous pouvez rediriger, mais ce n'est pas la même chose qu'un forward.

Ces fonctionnalités de l'application Web s'accordent donc contre votre volonté de les déployer de manière homogène dans le conteneur.

Je pense plutôt que le bon plan consiste à créer un "assembleur". utilitaire qui prend vos modules individuels et "fusionne" les dans une seule application Web. Il peut fusionner leur fichier web.xml, leur contenu, normaliser les fichiers jars et les classes, etc.

Les WAR sont une fonctionnalité et un bogue du monde Java. Je les adore car ils déploient réellement des applications compilées "Glisser-déposer". en termes d'installation, et cette fonctionnalité est utilisée beaucoup plus que ce que vous rencontrez. Mais je ressens ta douleur. Nous avons un " noyau " commun cadre que nous partageons entre les applications, et nous devons fondamentalement le fusionner en permanence pour le maintenir. Nous l'avons écrit dans les scripts, mais cela reste un peu pénible.

Answer 5

"De plus, je ne sais pas si vous pouvez effectuer un" transfert ". vers un autre WAR du serveur. Le problème est que les transferts utilisent une URL relative à la racine de l'application Web et que chaque application Web a sa propre racine, vous ne pouvez donc tout simplement pas y accéder à partir de cet endroit. Vous pouvez rediriger les messages, mais ce n'est pas la même chose qu'un transfert. "

Vous pouvez transférer vers un autre fichier WAR tant que ce fichier permet à quelqu'un de le faire.

glassfish et les multiples WAR d'un EAR: cela a du sens.

Si vous placez les classes MAIN dans le CLASSPATH partagé de tomcat, vous pouvez alors placer vos PLUGIN individuels dans des fichiers WAR distincts.

L'application Main peut également faire partie du servlet TOMCAT que vous définissez dans server.xml. Cela peut être le MASTER SERVLET et tous les autres WAR peuvent être contrôlés par ce servlet principal.

Est-ce que cela a du sens?

BR,
~ A

Answer 6

En fonction de la complexité de la fonctionnalité du plug-in, je considérerais également un service Web, par exemple implémenté avec Axis.

Votre application principale est ensuite configurée avec l'URL de l'application Web (plug-in) fournissant le service.

L’avantage, selon moi, est double:

• Vous obtenez une belle, propre, API débogable entre les deux guerres, à savoir le Messages SOAP / XML
• Vous pouvez mettre à niveau un seul plugin sans avoir à tester votre régression. toute l'application

Les inconvénients sont que vous devez mettre en place des projets Axis et que vous devez avoir sorte de configuration du plugin. En outre, vous devrez peut-être limiter l’accès à vos services Web. applications, donc un peu de configuration peut être nécessaire.

Si les plugins fonctionnent sur la même base de données, assurez-vous de limiter le temps de cache ou de configurer un serveur War-Spanning. couche de mise en cache.

Answer 7

J'ai également essayé de développer un cadre commun ou abstrait dans lequel je peux ajouter des plugins (ou des modules) au moment de l'exécution et améliorer l'application Web existante en cours d'exécution.

Maintenant, comme vous l'avez dit, préférait le faire en utilisant un fichier WAR ou JAR. Problème avec le fichier WAR, vous ne pouvez pas déployer en tant que plug-in vers une application existante. Tomcat le déploiera en tant que contexte Web distinct. Pas souhaitable.

Une autre option consiste à créer un fichier JAR et à écrire du code personnalisé pour copier ce fichier JAR dans le dossier WEB-INF / lib et charger les classes dans le chargeur de classes existant. Le problème est de savoir comment déployer des fichiers non-Java tels que JSP ou des fichiers de configuration. Pour cela, il y a deux solutions, a. Utilisez des modèles de vélocité au lieu de JSP (b.) Écrivez du code personnalisé pour lire JSP à partir du chemin de classe au lieu du chemin de contexte.

Les modules OSGI ou Spring Dynamic sont bien, mais pour le moment, ils me paraissent excessivement complexes. Je vais examiner à nouveau, si je me sens.

Je recherche une API simple, qui peut prendre en charge le cycle de vie du plug-in et qui peut toujours utiliser les JSP dans mon fichier JAR empaqueté.

Peut-être, vous pouvez utiliser jar le plugin au moment du déploiement et copier les fichiers dans les répertoires de droite.

Answer 8

En réalité, rien n’est meilleur que OSGI si vous envisagez de scinder une application en modules distincts. Jetez un coup d'œil à l'exemple de Greenpages. Vous pouvez créer un module parent (noyau) dans lequel vous incluez les jars dont votre application a besoin.

Si vous connaissez la programmation de composants, vous découvrirez bientôt que les modules OSGI se comportent comme des interfaces, où vous devez exposer ce que vous utiliserez dans d'autres modules. C'est assez simple une fois que vous avez compris. Quoi qu'il en soit, cela peut aussi être très pénible d'apprendre à utiliser OSGI. Nous avons eu des problèmes d’utilisation de JSON, car une version de Jackson que nous avons ajoutée en tant que fichier jar au module a été remplacée par un autre fichier jar contenu dans les modules de base de Spring. Vous devez toujours vérifier quelle version de jar est chargée pour vos besoins.

Malheureusement, même l’approche OSGI ne résout pas ce que nous recherchons. Comment étendre un modèle persistant et des formulaires existants au moment de l'exécution.