Come rendere modulare un JSF / Facelets / applicazione primavera con OSGi?

StackOverflow https://stackoverflow.com/questions/2575669

Domanda

Sto lavorando con le applicazioni / Facelets molto grande JSF che utilizzano primavera per la gestione dei DI / fagiolo. Le mie applicazioni hanno struttura modulare e sto attualmente alla ricerca di approcci per standardizzare la modularizzazione.

Il mio obiettivo è quello di comporre un'applicazione web da una serie di moduli (possibilmente in base a vicenda). Ogni modulo può contenere il seguente:

  • Corsi;
  • risorse statiche (immagini, CSS, script);
  • modelli facelet;
  • fagioli Managed - contesti applicativi di primavera, con richiesta di sessione e fagioli di applicazioni di ambito (alternativa è JSF gestito fagioli);
  • roba API Servlet -. Servlet, filtri, ascoltatori (questo è opzionale)

Quello che mi piacerebbe da evitare (quasi a tutti i costi) è la necessità di copiare o risorse del modulo estratto (come template Facelets) per la guerra o per estendere la web.xml per servlet del modulo, filtri, ecc Deve essere abbastanza aggiungere il modulo (JAR, fascio, artefatto, ...) all'applicazione web (WEB-INF/lib, bundles, plugins, ...) per estendere l'applicazione web con questo modulo.

Al momento ho risolvere questo compito con una soluzione modularizzazione consuetudine che è fortemente basata sull'utilizzo di risorse classpath:

  • mezzi speciali di servlet serve risorse statiche dalle risorse classpath (JAR).
  • Speciale Facelets risorsa resolver permette il caricamento di modelli facelet da risorse classpath.
  • contesti applicativi carichi di primavera via classpath*:com/acme/foo/module/applicationContext.xml modello -. Questa applicazione carichi contesti definiti nella JAR modulo
  • Infine, una coppia di delega servlet e filtri delegato elaborazione richiesta alle servlet e filtri configurati in contesti applicativi Spring dai moduli.

Ultimi giorni ho letto un sacco di OSGi e stavo considerando, come (e se) ho potuto usare OSGi come un approccio standardizzato modularizzazione. Stavo pensando a come attività individuale potrebbe essere risolto con OSGi:

  • statici risorse - fasci OSGi che intendono esportare risorse statiche registrare un istanze ResourceLoader con il contesto fascio. Un ResourceServlet centrale utilizza questi caricatori di risorse alle risorse carico da pacchi.
  • facelet modelli -. Simile al precedente, una centrale Services utilizza ResourceResolver registrati da fasci
  • fagioli Managed -. Non ho idea come utilizzare un'espressione come se #{myBean.property} myBean è definito in uno dei bundle
  • Servlet API roba -. Uso qualcosa come WebExtender / Pax Web per registrare servlet, filtri e così via

Le mie domande sono:

  • I Am inventare una bicicletta qui? Ci sono soluzioni standard per questo? Ho trovato una menzione di primavera fette ma non ho trovato molta documentazione su di esso.
  • Pensi che OSGi è la tecnologia giusta per l'incarico?
  • Il mio schizzo di applicazione OSGI più o meno corretto?
  • Come dovrebbe gestito fagioli (soprattutto richiesta / sessione di portata) essere gestita?

sarei generalmente grati per i tuoi commenti.

È stato utile?

Soluzione

Che cosa si sta puntando a fare suoni fattibile, con alcune precisazioni:

The View strato: In primo luogo, il vostro livello di vista sembra un po 'overstuffed. Ci sono altri modi per rendere modulare componenti JSF utilizzando componenti personalizzati che consentano di evitare il mal di testa coinvolti con il tentativo di creare qualcosa di così drammatico come fagioli gestiti late-binding.

I moduli stessi: In secondo luogo, i moduli non sembrano particolarmente modulare. Il tuo primo proiettile-list rende il suono come se si sta cercando di creare applicazioni web interoperabili, piuttosto che i moduli di per sé. Mia idea di un modulo è che ciascun componente ha un ben definito, e più o meno discreti, scopo. Come come ex sottende vi . Se stai andando giù il percorso OSGi, allora dovremmo definire modulare in questo modo: modulare, per il bene di questa discussione, significa che i componenti sono sostituibili a caldo - che è, possono essere aggiunti e rimosso senza rompere l'applicazione.

Dipendenze: "possibilmente a seconda vicenda" sono un po 'preoccupato per il descrizione dei moduli come Probabilmente (spero) già lo sanno, ma le dipendenze dovrebbero formare un grafo orientato aciclico. Una volta che si introduce una dipendenza circolare, si sta chiedendo per un mondo di male in termini di eventuale manutenzione della app. Uno dei più grandi debolezze di OSGi è che non a prevenire dipendenze circolari, quindi sta a voi per far rispettare questo. In caso contrario, le dipendenze cresceranno come kudzu e soffocare gradualmente il resto dell'ecosistema del sistema.

Servlet: Fuhgeddaboudit. È possibile servlet non in ritardo-bind in una web app, non fino a quando le specifiche Servlet 3.0 è in produzione (come Pascal ha sottolineato). Per avviare una servlet utility separata, è necessario metterlo in una propria app.

OK, tanto per i caveat. Pensiamo a come questo lavoro potrebbe:

Hai definito il proprio modulo JSF fare ... che cosa, esattamente? Diamogli un definito, obiettivo abbastanza banale: una schermata di login. Così si crea la schermata di login, in ritardo-bind utilizzando OSGi nella vostra app e ... poi? Come fa l'applicazione conosce la funzionalità di login è lì, se non è stato definito nella tua pagina .jspx? Come fa l'applicazione sa per navigare a qualcosa che non può sapere è lì?

Ci sono modi per aggirare questo utilizzando condizionale comprende e simili (ad esempio, <c:if #{loginBean.notEmpty}>), ma, come hai detto tu, le cose si fanno un po 'peloso quando il vostro gestito loginBean esiste in un altro modulo che potrebbero non essere nemmeno stato introdotto per la eppure app. In realtà, si otterrà un'eccezione servlet a meno che non esista che loginBean. Quindi, che cosa fate?

È possibile definire un'API in uno dei vostri moduli. Tutti i fagioli gestiti che si intende condividere tra i moduli devono essere specificati come interfacce in questo strato di API. E tutti i moduli devono avere implementazioni di default di una qualsiasi di queste interfacce che intendono utilizzare. E questa API deve essere condivisa tra tutti i moduli interoperabili. Quindi è possibile utilizzare OSGi e Spring cablare insieme i fagioli specificati con la loro attuazione.

Ho bisogno di prendere un momento per sottolineare che questo non è come vorrei affrontare questo problema. Affatto. Dato qualcosa come semplice come una pagina di login, o addirittura complicato come un grafico azionario, io personalmente preferisco creare un componente JSF personalizzato. Ma se il requisito è "Voglio che i miei fagioli gestite per essere modulare (vale a dire, hot-swap, ecc)," questo è l'unico modo che conosco per farlo funzionare. E non sono neanche del tutto sicuro che il lavoro sarà. Questo scambio di email suggerisce che si tratta di un problema che JSF gli sviluppatori hanno appena iniziato a lavorare su.

Normalmente considerano riuscito fagioli per essere parte del livello vista, e come tali li uso solo per vista lOGIC, e delegare tutto il resto per il livello di servizio. Fare fagioli gestiti late-binding è, a mio avviso, promuovendo fuori dello strato di vista e nella logica di business. C'è un motivo per cui tutti questi tutorial sono così concentrati sui servizi: perché la maggior parte del tempo si desidera prendere in considerazione quello che ci vorrebbe per la vostra applicazione per eseguire "senza testa", e come sarebbe facile a "pelle" la vostra vista se, per esempio, si voleva a correre, con tutte le sue funzionalità, su un telefono Android.

Ma suona come un sacco di ciò che si sta lavorando è di per sé vista la logica - per esempio, la necessità di scambio in un diverso modello di vista. OSGi / primavera dovrebbe essere in grado di aiutare, ma avrete bisogno di qualcosa nella tua app per scegliere tra implementazioni disponibili: più o meno quello del Registro di Servizio di OSGi è stato costruito per fare.

che lascia statiche risorse. È possibile rendere modulare questi, ma ricordate, è necessario definire un'interfaccia per recuperare queste risorse, e avrete bisogno di fornire un'implementazione di default in modo la vostra applicazione non soffocare se sono assenti. Se i18n è una considerazione, questo potrebbe essere un buon modo per andare. Se si voleva essere davvero avventuroso, allora si potrebbe spingere le risorse statiche in JNDI. Che renderebbe completamente sostituibili a caldo, e risparmiare il dolore di cercare di risolvere quale implementazione usare programmazione, ma ci sono alcuni aspetti negativi: qualsiasi ricerca fallito causerà il vostro app per gettare un NamingException. Ed è eccessivo. JNDI è normalmente utilizzato in applicazioni web per la configurazione app.

Per quanto riguarda le vostre domande rimanenti:

  

I Am inventare una bicicletta qui? Ci sono soluzioni standard per questo?

Sei, un po '. Ho visto le applicazioni che fanno questo tipo di cose, ma sembra che tu abbia inciampato in una serie piuttosto unico di requisiti.

  

Pensi che OSGi è la tecnologia giusta per l'incarico?

Se avete bisogno dei moduli di essere hot-swap, quindi le scelte sono OSGi e l'interfaccia ServiceLocator più leggera.

  

Il mio schizzo di applicazione OSGI più o meno corretto?

Non posso davvero dire senza sapere di più su dove i vostri confini componenti sono. Al momento, suona come si può essere spingendo OSGi a fare di più di quello che è capace di fare.

Ma non prendere la mia parola. ho trovato altro materiale di lettura in questi luoghi.

E poiché si chiede su Spring Fette, questo dovrebbe essere sufficiente per iniziare . Avrete bisogno di un client Git, e sembra come se ti stessi essere formazione sul app, cercando attraverso il codice sorgente. Ed è il codice prototipo molto presto.

Altri suggerimenti

Sono di fronte gli stessi problemi nel mio progetto attuale. A mio parere, OSGi è la soluzione migliore e più pulita in termini di standard e il supporto futuro, ma attualmente si può colpire alcuni problemi se si tenta di utilizzarlo in un'applicazione web:

  1. non c'è ancora ben integrato soluzione tra un contenitore Web e la piattaforma OSGi.
  2. OSGi potrebbe essere troppo per un'applicazione web di generazione personalizzata che è solo alla ricerca di un semplice un'architettura modulare. Vorrei prendere in considerazione OSGi se le mie esigenze di progetto per supportare estensioni di terze parti che non sono al 100% sotto il nostro controllo, se il progetto ha bisogno di riassegnazioni calde, rigide regole di accesso tra i plugin, ecc.

Una soluzione personalizzata basata su caricatori di classe e filtri di risorse sembra molto appropriata per me. A titolo di esempio si può studiare la Hudson codice sorgente o plug-in Java Framework (JPF) Progetto (http://jpf.sourceforge.net/).

Per quanto di estendere il web.xml, ci può essere fortunati con le specifiche Servlet 3.0 (http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3 .html # innestabilità-e-estensibilità).

Il "web modulo di deployment descriptor frammento" (aka web-fragment.xml) introdotto dalla Servlet specifica 3.0 sarebbe bello qui. La specifica definisce come:

  

Un frammento web è una logica   partizionamento del web app in tale   modo che i quadri utilizzati   all'interno della app web può definire tutte le   artefatti senza chiedere devlopers a   modificare o aggiungere informazioni nel   web.xml.

Java EE 6 non è forse un'opzione per voi in questo momento però. Eppure, sarebbe la soluzione standardizzata.

Enterprise OSGi tratta di un nuovo dominio in modo non penso che si otterrà una soluzione che soddisfa direttamente il vostro bisogno. Detto questo una delle cose che ho trovato mancante da Equinox (motore OSGi dietro eclisse e, quindi, uno con la più grande base di utenti!) È una configurazione del servizio coerente / DI. Nel mio progetto di recente abbiamo avuto alcune esigenze simili e si è conclusa la costruzione di un semplice servizio di configurazione OSGi.

Uno dei problemi che saranno inerente applicazioni modulari sarebbe intorno DI, la visibilità modulo potrebbe impedire l'accesso classe in alcuni casi. Abbiamo ottenuto intorno a questo utilizzando un criterio di iscritti-amico, che non è troppo ideale, ma funziona.

Oltre la configurazione, è possibile dare un'occhiata al libro Equinox recentemente pubblicato per la guida all'uso di OSGi come base per la creazione di applicazioni modulari. Gli esempi possono essere specifiche per Equinox, ma i principi funzionerebbero con qualsiasi quadro OSGi. Collegamento - http://equinoxosgi.org/

Si dovrebbe guardare in primavera DM Server (è in fase di transizione a Eclipse Vergine, ma che non è stato ancora rilasciato). C'è un sacco di cose buone nella recente specifiche OSGi enterprise che è anche stato appena rilasciato.

Alcuni dei tutorial primavera DM aiuterà, mi immagino. Ma sì, è possibile avere sia le risorse e le classi caricate da fuori Web Bundle con modularità standard. In questo, è una buona misura.

Per quanto riguarda il contesto di sessione - che venga gestito come ci si aspetterebbe in una sessione. Tuttavia, si potrebbe incorrere in problemi con la condivisione che sessione tra fasci web al punto che in non è sicuro se è ancora possibile.

Si potrebbe anche cercare di avere un unico bundle web e poi usare per esempio il Registro di estensione Eclipse per estendere le funzionalità di voi web app.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top