Comment modularisation un JSF / Facelets / application Spring avec OSGi?

https://stackoverflow.com/questions/2575669

24-09-2019
|

Question

Je travaille avec une très grande applications JSF / Facelets qui utilisent Spring pour la gestion DI / haricot. Mes applications ont une structure modulaire et je suis actuellement à la recherche d'approches pour normaliser la modularisation.

Mon but est de composer une application web à partir d'un certain nombre de modules (éventuellement en fonction de l'autre). Chaque module peut contenir les éléments suivants:

Classes;
Ressources statiques (images, CSS, scripts);
Modèles de Facelet;
Les beans gérés - contextes d'application de printemps, avec la demande, la session et les haricots portée application (alternative est JSF géré les haricots);
Servlet choses API -. Servlets, les filtres, les auditeurs (facultatif)

Ce que je voudrais éviter (presque à tout prix) est la nécessité de copier ou extraire les ressources du module (comme modèles Facelets) à la guerre ou à étendre les servlets du web.xml pour le module, les filtres, etc. Il doit être assez pour ajouter le module (JAR, paquet, objet, ...) à l'application Web (WEB-INF/lib, bundles, plugins, ...) pour étendre l'application Web avec ce module.

Actuellement, je résous cette tâche avec une solution de modularisation personnalisée qui est fortement basée sur l'utilisation des ressources classpath:

servlet ressources spéciales sert des ressources statiques des ressources classpath (JAR).
résolveur de ressources spéciales Facelets permet le chargement des modèles de Facelet des ressources classpath.
charges de printemps contextes d'application via le modèle classpath*:com/acme/foo/module/applicationContext.xml - ceci charge des contextes d'application définis dans le module JARs
Enfin, une paire de délégation demande délégué des servlets et des filtres de traitement pour les servlets et les filtres configurés dans des contextes d'application à ressort à partir de modules.

jours, j'ai lu beaucoup de choses sur OSGi et je considérais, comment (et si) je pouvais utiliser OSGi comme une approche standardisée modularisation. Je pensais à la façon dont les tâches individuelles pourraient être résolus avec OSGi:

Ressources statiques - bundles OSGi qui veulent exporter des ressources statiques enregistrent un cas de ResourceLoader avec le contexte du faisceau. Une ResourceServlet centrale utilise ces chargeurs de ressources pour charger des ressources à partir de faisceaux.
Modèles Facelet -. similaires ci-dessus, un ResourceResolver central utilise les services enregistrés par des faisceaux
Les beans gérés -. Je ne sais pas comment utiliser une expression comme #{myBean.property} si myBean est défini dans l'un des faisceaux
Servlet choses API - utiliser quelque chose comme WebExtender / Pax Web pour enregistrer les servlets, les filtres, etc.

Mes questions sont les suivantes:

Suis-je inventant un vélo ici? Y at-il des solutions standards pour cela? J'ai trouvé un de tranches de printemps mention mais ne pouvait pas trouver beaucoup de documentation à ce sujet.
Pensez-vous que OSGi est la bonne technologie pour la tâche décrite?
Mon croquis d'application OSGI plus ou moins correcte?
Comment devraient gérés haricots (demande en particulier / scope session) être traitée?

Je serais généralement reconnaissant pour vos commentaires.

La solution

Qu'est-ce que vous visez à faire des sons faisable, avec quelques mises en garde:

La couche Vue: Tout d'abord, votre couche de vue semble un peu rembourrées. Il existe d'autres façons de modularisation des composants JSF en utilisant des composants personnalisés qui permettront d'éviter les maux de tête impliqués en essayant de créer quelque chose d'aussi dramatique que les haricots gérés liaison tardive.

Les modules Eux-mêmes: Deuxièmement, vos modules ne semblent pas particulièrement modulaire. Votre première liste à puces fait sonner comme si vous essayez de créer des applications Web interopérables, plutôt que des modules en soi. Mon idée d'un module est que chaque composant a un, le but bien défini, et plus ou moins discrète. Comme la façon dont ex sous-tend vi . Si vous allez sur la route OSGi, nous devons définir comme celui-ci modulaire: modulaire, pour des raisons de cette discussion, signifie que les composants sont remplaçables à chaud - à savoir, ils peuvent être ajoutés supprimé sans casser l'application.

Dépendances: Je suis un peu préoccupé par votre description des modules comme « peut-être en fonction les uns des autres. » Vous avez sans doute (je l'espère) savent déjà, mais vos dépendances doivent former un graphe orienté acyclique. Une fois que vous introduisez une dépendance circulaire, vous demandez un monde de mal en termes de maintenabilité de l'application éventuelle. L'une des plus grandes faiblesses de OSGi est qu'il ne pas éviter les dépendances circulaires, il est donc à vous faire respecter cela. Sinon, vos dépendances pousseront comme kudzu et étouffer progressivement le reste de l'écosystème de votre système.

Servlets: . Fuhgeddaboudit Vous ne pouvez pas servlets fin de lier dans une application web, pas jusqu'à ce que la spécification Servlet 3.0 est dans la production (comme Pascal a souligné). Pour lancer un servlet utilitaire distinct, vous aurez besoin de le mettre dans sa propre application.

OK, tant pour les mises en garde. Réfléchissons sur la façon dont cela pourrait fonctionner:

Vous avez défini votre propre module JSF à faire ... quoi, exactement? Donnons un sens, le but assez trivial: un écran de connexion. Vous créez donc votre écran de connexion, bind-tard à l'aide d'OSGi dans votre application et ... alors quoi? Comment l'application connaît la fonctionnalité de connexion est là, si vous ne l'avez pas défini dans votre page française.jspx? Comment l'application sait naviguer à quelque chose qu'il ne peut pas savoir est là?

Il existe des moyens de contourner cela en utilisant conditionnelle comprend et similaires (par exemple, <c:if #{loginBean.notEmpty}>), mais, comme vous l'avez dit, les choses deviennent un peu poilu lorsque votre loginBean géré existe dans un autre module qui peut ne pas avoir même été présenté à la application encore. En fait, vous obtiendrez une exception servlet à moins que loginBean existe. Alors que faites-vous?

Vous définissez une API dans un de vos modules. Tous les haricots gérés que vous souhaitez partager entre les modules doivent être spécifiés comme interfaces dans cette couche API. Et tous vos modules doivent avoir des implémentations par défaut de l'une de ces interfaces qu'ils ont l'intention d'utiliser. Et cette API doit être partagée entre tous les modules interopérables. Ensuite, vous pouvez utiliser OSGi et au printemps pour câbler les grains spécifiés avec leur mise en œuvre.

Je dois prendre un moment pour souligner que ce n'est pas comment j'aborder ce problème. Pas du tout. Étant donné quelque chose comme aussi simple comme une page de connexion, ou même aussi compliqué que un graphique boursier, je préfère personnellement créer un composant JSF personnalisé. Mais si l'exigence est « Je veux que mes haricots réussi à être modulaire (à savoir, permutables à chaud, etc.), » c'est la seule façon que je connaisse pour le faire fonctionner. Et je ne suis pas tout à fait même que ce Travaillera . Cet échange de courrier électronique suggère qu'il est un problème qui JSF Les développeurs ont tout juste commencé à travailler.

Je considère normalement réussi les haricots à faire partie de la couche de vue, et en tant que tels que je les utilise uniquement pour une vue logic, et tout le reste à déléguer la couche de service. Faire des haricots gérés est en fin de liaison, à mon avis, leur promotion de la couche de vue et dans la logique métier. Il y a une raison pour laquelle tous ces tutoriels sont tellement concentrés sur les services: parce que la plupart du temps que vous voulez examiner ce qu'il faudrait pour votre application pour exécuter « sans tête », et comment il serait facile de « peau » votre point de vue si, pour par exemple, que vous vouliez à courir, avec toutes ses fonctionnalités, sur un téléphone Android.

Mais il semble que beaucoup de ce que vous travaillez avec lui-même est une logique de vue - par exemple, la nécessité d'échanger dans un modèle de vue différent. OSGi / printemps devrait être en mesure d'aider, mais vous aurez besoin de quelque chose dans votre application pour choisir entre les implémentations disponibles: à peu près ce service d'enregistrement de OSGi a été construit pour faire.

Il reste des ressources statiques. Vous pouvez modularisation ces derniers, mais rappelez-vous, vous devrez définir une interface pour récupérer ces ressources, et vous aurez besoin de fournir une implémentation par défaut de sorte que votre application ne s'étouffe pas s'ils sont absents. Si i18n est une considération, cela pourrait être une bonne façon d'aller. Si vous voulez être vraiment aventureux, vous pouvez pousser vos ressources statiques dans JNDI. Cela les rend complètement remplaçables à chaud, et vous sauver la douleur d'essayer de résoudre l'implémentation à utiliser un programme, mais il y a quelques inconvénients: une recherche échoué entraînera votre application pour lancer une NamingException. Et il est surpuissant. JNDI est normalement utilisé dans des applications web pour la configuration de l'application.

En ce qui concerne vos autres questions:

Suis-je inventant un vélo ici? Y at-il des solutions standards pour cela?

Vous êtes un peu. Je l'ai vu des applications qui font type de chose, mais vous semblez avoir trébuché dans un ensemble assez unique d'exigences.

Pensez-vous que OSGi est la bonne technologie pour la tâche décrite?

Si vous avez besoin des modules remplaçables à chaud, vos choix sont OSGi et l'interface ServiceLocator plus léger.

est mon croquis d'application OSGI plus ou moins correcte?

Je ne peux pas vraiment dire sans en savoir plus sur l'endroit où sont vos limites composants. À l'heure actuelle, il semble que vous pouvez pousser OSGi faire plus que ce qu'il est capable de faire.

Mais ne prenez pas ma parole. I trouvé tout autre matériel de lecture dans ces lieux.

Et puisque vous posez des questions sur Spring tranches,

Autres conseils

Je suis confronté aux mêmes problèmes dans mon projet actuel. À mon avis, OSGi est la meilleure et la plus propre solution en termes de normes et le soutien futur, mais actuellement vous pouvez frapper quelques problèmes si vous essayez de l'utiliser dans une application web:

il n'y a pas bien solution intégrée entre un conteneur Web et la plate-forme OSGi encore.
OSGi peut être trop pour une application Web de construction personnalisé qui est juste à la recherche d'une architecture simple et modulaire. Je considérerais OSGi si mon projet doit prendre en charge les extensions de tiers qui ne sont pas 100% sous notre contrôle, si le projet a besoin redéploiements chaud, les règles d'accès strictes entre les plug-ins, etc.

Une solution personnalisée basée sur les chargeurs de classes et les filtres de ressources semble très approprié pour moi. À titre d'exemple, vous pouvez étudier Hudson code source ou Java Plug-in cadre (JPF) projet (http://jpf.sourceforge.net/).

sur l'extension du web.xml, nous pouvons avoir de la chance avec la spécification Servlet 3.0 (http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3 .html # enfichabilité-et-extensibilité).

Le "module web fragment de descripteur de déploiement" (aka web-fragment.xml) introduit par le

Enterprise OSGi est un domaine relativement nouveau, alors ne vous pensez que vous obtiendrez une solution qui répond directement à vos besoins. Cela dit l'une des choses que j'ai manque d'Equinox (moteur derrière osgi éclipse et donc une avec le plus grand nombre d'utilisateurs!) Est un service de configuration / DI cohérente. Dans mon projet, récemment, nous avons eu des besoins similaires et a fini la construction d'une configuration simple service OSGi.

L'un des problèmes qui seront inhérents aux applications modulaires se situerait autour de DI, comme la visibilité du module pourrait empêcher l'accès de classe dans certains cas. Nous avons eu autour de cette aide d'une stratégie-ami enregistrée, ce qui est pas trop idéal, mais fonctionne.

Autre que la configuration, vous pouvez jeter un oeil sur le livre Equinox a récemment publié pour obtenir des conseils sur l'utilisation OSGi en tant que base pour la création d'applications modulaires. Les exemples peuvent être spécifiques à Equinox, mais les principes travailleraient avec tout cadre OSGi. Lien - http://equinoxosgi.org/

Vous devriez regarder dans Spring DM Server (il est en cours de transition vers Eclipse Virgo mais ce n'est pas encore sorti). Il y a beaucoup de bonnes choses dans la récente spécification d'entreprise OSGi qui a également d'être libérés.

Certains des tutoriels DM Spring aidera, je l'imagine. Mais oui, il est possible d'avoir les ressources et les classes chargées de l'extérieur du faisceau Web en utilisant la modularité standard. En cela, il est un bon ajustement.

En ce qui concerne le contexte de la session - il se traité comme on peut s'y attendre dans une session. Cependant, vous pourriez rencontrer des problèmes avec le partage de cette session entre les faisceaux Web dans la mesure où en ne sais pas s'il est même possible.

Vous pouvez aussi regarder d'avoir un paquet Web unique et ensuite utiliser par exemple le registre d'extension Eclipse pour étendre les capacités de vous application web.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow