Estensione di applicazioni Web Java con plug-in

Question

Ho questa applicazione web che è diventata un casino ingestibile.

Voglio dividerlo in un comune "framework" parte (che include ancora elementi Web come pagine e immagini) e diversi moduli che aggiungono funzionalità e schermate extra. Voglio che questo refactoring sia utile anche come sistema di plugin per estensioni di terze parti.

Tutti i moduli devono essere unità di distribuzione separate, idealmente un file war o jar.

Ho provato a creare solo diversi file di guerra regolari, ma Tomcat mantiene (secondo le specifiche del servlet) questi file di guerra completamente separati l'uno dall'altro, in modo che non possano condividere le loro classi, ad esempio.

Ho bisogno di plugin per essere in grado di vedere " main " classpath.

Ho bisogno dell'applicazione principale per avere un po 'di controllo sui plugin, come essere in grado di elencarli e impostarne la configurazione.

Vorrei mantenere una completa separazione tra i plugin stessi (a meno che non specifichino dipendenze) e qualsiasi altra applicazione web non correlata che potrebbe essere in esecuzione sullo stesso Tomcat.

Vorrei che fossero radicati sotto " main " prefisso URL dell'applicazione, ma non è necessario.

Vorrei usare Tomcat (grandi cambiamenti architettonici devono essere coordinati con troppe persone), ma anche per sapere se esiste una soluzione pulita nel mondo EJB o OSGi.

Answer 1

Ho armeggiato con l'idea di usare OSGi per risolvere lo stesso problema che stai descrivendo. In particolare, sto cercando di utilizzare Spring Dynamic Modules .

Answer 2

Dai un'occhiata ai portlet Java - http://developers.sun.com / portalserver / reference / techart / jsr168 / - in poche parole, una specifica che consente l'interoperabilità tra quelle che sono applicazioni web j2ee altrimenti indipendenti

Modifica Ho dimenticato di dire che i Portlet sono praticamente indipendenti dal framework, quindi puoi usare Spring per l'applicazione padre e i singoli sviluppatori possono usare quello che vogliono sui loro Portlet.

Answer 3

Hai mai provato a usare Maven per separare i tuoi progetti e poi hai risolto le dipendenze tra WAR e JAR? Finirai con la duplicazione delle librerie tra WAR, ma solo dove è necessario (e questo non dovrebbe essere un problema a meno che non ti diverta in un funky classloader).

Tomcat ti consente anche di configurare applicazioni cross-context se devi passare da una WAR all'altra in modo relativamente trasparente ...

Se si desidera mantenere le cose nella stessa singola app Web (ad esempio ROOT), è possibile creare una webapp proxy che inoltri attraverso l'altra webapp pertinente dietro le quinte affinché l'utente possa renderla relativamente trasparente?

Answer 4

Il tuo problema principale sarà incentrato sulle risorse fisiche e statiche del sistema - il resto è semplicemente, efficacemente, vasetti.

I WAR sono separati, in Tomcat, con classloader separati ma anche separati a livello di sessione (ogni WAR è un'app Web individuale e ha il proprio stato di sessione).

In Glassfish, se i WAR fossero raggruppati in una EAR, avrebbero condiviso i caricatori di classi (GF utilizza uno spazio caricatore di classi piatte nelle EAR), ma avrebbero comunque uno stato di sessione separato.

Inoltre, non sono sicuro che tu possa fare un " forward " a un'altra GUERRA nel server. Il problema è che i forward utilizzano un URL relativo alla radice dell'app Web e ogni WebApp ha la propria radice, quindi semplicemente "non puoi arrivarci da qui". Puoi reindirizzare, ma non è la stessa cosa di un forward.

Quindi queste funzionalità dell'app Web cospirano contro di te cercando di distribuirle in modo omogeneo all'interno del contenitore.

Penso piuttosto che il suggerimento è creare un "assemblatore" utility che accetta i tuoi singoli moduli e "unisce" " in un'unica app Web. Può unire il loro web.xml, il loro contenuto, normalizzare i vasetti e le classi, ecc.

Le GUERRE sono una funzionalità e un bug nel mondo Java. Li adoro perché fanno davvero la distribuzione di applicazioni compilate " Trascina selezione " " in termini di installazione, e questa funzionalità è utilizzata molto più di ciò che stai incontrando. Ma sento il tuo dolore. Abbiamo un "core" comune framework che condividiamo tra le app e fondamentalmente dobbiamo fonderlo continuamente per mantenerlo. L'abbiamo scritto, ma è ancora un po 'doloroso.

Answer 5

" Inoltre, non sono sicuro che tu possa fare un " forward " a un'altra GUERRA nel server. Il problema è che i forward utilizzano un URL relativo alla radice dell'app Web e ogni WebApp ha la propria radice, quindi semplicemente "non puoi arrivarci da qui". Puoi reindirizzare, ma non è la stessa cosa di un forward. & Quot;

Puoi inoltrare a un'altra GUERRA fintanto che quella GUERRA consente a qualcuno di farlo.

pesce vetro e più GUERRE di un'AERICA: questo ha senso.

Se metti le classi MAIN nel CLASSPATH condiviso di tomcat, puoi mettere i tuoi singoli PLUGIN in file WAR separati.

L'app principale può anche far parte del servlet TOMCAT definito in server.xml. Questo può essere il SERVTER MASTER e tutti gli altri WAR possono essere controllati da questo servlet master.

Ha senso?

BR,
~ A

Answer 6

A seconda della complessità della funzionalità del plug-in, prenderei in considerazione anche un servizio Web, ad esempio implementato con Axis.

La tua applicazione principale viene quindi configurata con l'URL dell'applicazione Web (plugin) che fornisce il servizio.

Il vantaggio, secondo me, è duplice:

• Tra le due guerre si ottiene un'API piacevole, pulita e di debug, vale a dire la Messaggi di sapone / XML
• Sei in grado di aggiornare un singolo plugin senza dover testare la regressione del tuo intera applicazione

Gli svantaggi sono che devi impostare alcuni progetti Axis e che devi averne alcuni sorta di configurazione del plugin. Inoltre, potresti dover limitare l'accesso al tuo servizio web applicazioni, quindi potrebbe essere necessario un po 'di configurazione.

Se i plugin funzionano sullo stesso database assicurati di limitare il tempo di cache o di configurare un war-spanning livello di memorizzazione nella cache.

Answer 7

Ho anche provato a sviluppare un framework comune o astratto in cui posso aggiungere plug-in (o moduli) in fase di esecuzione e migliorare la webapp in esecuzione esistente.

Ora, come hai detto, preferivo un modo per farlo usando il file WAR o JAR. Il problema con il file WAR è che non è possibile distribuire come plug-in all'app esistente. Tomcat lo distribuirà come contesto Web separato. Non desiderabile

Un'altra opzione è il file JAR e scrivere del codice personalizzato per copiare quel file JAR nella cartella WEB-INF / lib e caricare le classi nel programma di caricamento classi esistente. Il problema è come distribuire file non Java come JSP o file di configurazione. Per questo, ci sono due soluzioni, a. Utilizzare i modelli di velocità anziché JSP (b.) Scrivere del codice personalizzato per leggere JSP dal percorso di classe anziché dal percorso di contesto.

I moduli OSGI o Spring Dynamic sono belli, ma al momento mi sembrano eccessivamente complessi. Lo esaminerò di nuovo, se ne avrò la sensazione.

Sto cercando una semplice API, che possa occuparsi del ciclo di vita del plugin e ancora in grado di usare i JSP nel mio file JAR in pacchetto.

Può essere, è possibile utilizzare un jar il plug-in al momento della distribuzione e copiare i file nelle directory giuste.

Answer 8

In realtà non c'è niente di meglio dell'OSGI se stai pensando di dividere l'applicazione in moduli separati. Dai un'occhiata all'esempio di Greenpages. Puoi creare un modulo genitore (core) in cui includi barattoli necessari per la tua applicazione.

Se sai qualcosa sulla programmazione dei componenti, scoprirai presto che i moduli OSGI si comportano come interfacce, dove devi esporre ciò che userai in altri moduli. È abbastanza semplice una volta capito. Comunque può anche essere molto doloroso quando impari a usare OSGI. Abbiamo avuto problemi con l'utilizzo di JSON, come versione di Jackson che abbiamo aggiunto come jar al modulo, è stato sovrascritto da altri jar contenuti nei moduli core di Spring. Devi sempre ricontrollare quale versione di jar è stata caricata per le tue esigenze.

Purtroppo anche l'approccio OSGI non risolve ciò che stiamo cercando. Come estendere un modello persistente e moduli esistenti in fase di esecuzione.