Architecture "plugin" d'application Web Java


Veuillez donner un conseil sur la façon de faire une architecture "plugin" pour une application Web Java.

Actuellement, nous utilisons Spring+Hibernate+Struts 2 assez simple et standard dans le conteneur de servlet Tomcat. (Construit avec maven)

J'ai besoin de quelque chose comme Redmine. Où n'importe quel module peut être activé / désactivé, mis à jour Interface UTILISATEUR Redmine

Veuillez exclure les options lourdes comme OSGi, Portlet.

  • OSGi est trop lourd, il n'y a pas de bonne adoption de la technologie pour le web. Je l'ai déjà regardé Eclipse Germini;
  • Portlet il est juste vieux, et n'a jamais été populaire.
Author: Aliaksandr Belik, 2013-01-16

3 answers

Je vais essayer de fournir plusieurs solutions possibles. J'ai passé du temps à préparer de petits POC pour le projet sur lequel je travaille, alors espérons que les options ci-dessous sont pertinentes.

Note importante: il est vraiment facile de définir un point d'extension, de résoudre et de trouver des implémentations disponibles. Il y a beaucoup de solutions disponibles, par exemple une bonne et simple -- JSPF

Les Ressources sont le principal problème pour le WEB les applications de

OSGi

OSGi, n'est pas si mauvais et peut être utile. Cela semble être lourd (et certaines implémentations sont lourdes) mais c'est le prix de la plate-forme standardisée. Je suggère de vérifier Apache Felix. Il peut être utilisé en mode "léger". En passant, il comprend une console Web qui est construite en tant qu'application basée sur un plugin faiblement couplé, pourrait être utile:

entrez la description de l'image ici

Quelques exemples Extension du Web Apache Felix Console

La console Web peut être étendue en enregistrant un service OSGi pour l'interface javax.servlet.Servlet avec la propriété service Félix.webconsole.étiquette définie sur l'étiquette (dernier segment de l'URL) de page. Le service respectif est appelé un plugin de console Web ou un plugin pour faire court.

Vous pouvez également vérifier eie-manager qui est propre et simple et utilise OSGi pour gérer les plugins. Pourrait être un bon exemple pour vous.

Cadre de plugin personnalisé

Je suggère de revoir la solution derrière Jenkins/Hudson. Je dirais que le système de plug-in Jenkins est assez mature et fiable. Peut être utilisé comme un bon exemple.

entrez la description de l'image ici

Veuillez également vérifier Hudson Architecture de Plugin

Solution simple

Pour mon projet, j'ai construit une couche d'abstraction de plugin basée sur JSPF avec un résolveur de dépendance personnalisé.

AVANTAGES:

  • simple et petit
  • concept propre
  • fonctionne bien

INCONVÉNIENTS:

  • sans une bonne gestion du plugin peut être lente (recherche complète de classpath)
  • fournit des fonctionnalités très basiques
  • peut nécessiter une attention supplémentaire

Je suggère d'utiliser JSPF uniquement si vous avez vraiment besoin de simplicité et que vous voulez tout contrôler. JPF fournit de nombreuses fonctionnalités intéressantes boîte, par exemple:

Les plug-ins peuvent être "enregistrés à chaud" et même désenregistrés pendant exécution de l'application. Qui plus est, des plugins peuvent être activé et désactivé "à la volée", minimisant les ressources d'exécution utilisation.

Le problème est que JPF est mort.

Suggestion

Passez du temps avec Apache Felix. Il est assez mature, donc vos investissements en temps peuvent rapporter beaucoup.

 13
Author: Renat Gilmanov, 2013-06-21 13:40:50

Découvrez les réponses à cette question: Meilleure façon de construire un système de Plugin Java

Si vous ne faites pas confiance au code du plugin, vous pouvez implémenter le sandboxing, comme décrit ici: Sandbox contre le code malveillant dans une application Java

Le projet open-source Java Plug-in Framework prend en charge la désactivation du plugin, vous pouvez vous en inspirer même s'il est trop lourd pour vos besoins.

 6
Author: lbalazscs, 2017-05-23 12:17:17

Atlassian a ouvert son système de pluginsici . Je vois que l'équipe Atlassian travaille beaucoup. Cela vaut la peine d'explorer sa documentation

 2
Author: asyncwait, 2014-01-06 18:50:01