OSGi - Quanto è matura questa tecnologia?

Question

Ho un requisito in cui ho bisogno di condividere alcune risorse web (jsp, html, js, images, css etc.) attraverso diversi Spring basate Struts 2 applicazioni. E sembra che lo OSGi possa essere usato per raggiungere questo obiettivo?

• qualcuno può dare alcune indicazioni su come raggiungere questo obiettivo con OSGi?
• E in secondo luogo voglio sapere è OSGi abbastanza maturo da essere utilizzato nelle applicazioni di produzione?

Grazie in anticipo!

EDIT: ho passato this posta e sembra che le persone sono in grado di condividere un fascio web attraverso applicazioni web. L'unica differenza è che lo hanno fatto con Spring MVC. Voglio sapere se questo può essere ottenuto anche con le applicazioni Struts2?

EDIT 2: Io sono fondamentalmente poco chiare circa il seguente:

• disposta la 'condivisibile-fascio' (che contiene le risorse web da condividere) una .war confezionato. Se sì, allora da dove verrà formato il contesto web finale poiché questo pacchetto verrà nuovamente condiviso con l'applicazione principale "web"? Mi aspetto che il contesto web finale sia formato dall'unione del "pacchetto condivisibile" e dell'applicazione web "principale". Accadrà automaticamente? Qualche idea?

Answer 1

Mentre OSGI potrebbe essere una soluzione, potrebbe essere un po 'eccessivo (e, come Bozho sottolineato, avrete bisogno di un contenitore capace OSGI).Forse dare un'occhiata a How to share resources across projects in Maven per altre opzioni:

• Cut e incollarli.
• Usa Assembly e Dependency plugin
• Utilizzare i maven-remote-resources-plugin

In questo blog vi mostrerò come fare la seconda opzione poiché a mio parere, è attualmente il più stabile e flessibile. In futuro proverò con lo il plug-in maven-remote-resources e scrivendo un tutorial.

MODIFICA: per rispondere a un commento dall'OP. Sì, l'idea è di creare un assemblaggio delle risorse web condivisibili e di utilizzare il plug-in maven-dependency per estrarre l'assembly nei progetti "resource-consumer". Tutto questo è spiegato e dettagliato nel post del blog sopra menzionato. Fammi sapere se qualcosa non è chiaro in esso.

Answer 2

OSGi viene utilizzato in Eclipse, GlassFish, ServiceMix (e altri anche), che sono prodotti software maturi. Tuttavia, sono di natura molto specifica e la mia opinione personale è che OSGi non è adatto ai progetti di tipo comune. Per quanto ne so (qualcuno mi corregga, se ci sono notizie in quest'area), se si desidera utilizzare OSGi con applicazioni Web, è necessario un contenitore servlet in bundle OSGi. Inoltre, mettere risorse (html, js, immagini) in bundle OSGi può essere problematico.

Answer 3

OSGi è una tecnologia abbastanza matura - questo è il modo in cui sono strutturati tutti i plugin di Eclipse. Tuttavia, la tecnologia deve ancora guadagnare spazio nello spazio delle app Web perché ci sono pochissimi contenitori servlet che la supportano.

Se si desidera leggere su di esso, è necessario controllare Modular Java di Craig Wells, in quanto fornisce uno sfondo abbastanza buono su OSGi in relazione al Framework di primavera.

Per quanto riguarda la condivisione delle risorse, è consigliabile esaminare un pacchetto EAR. Ho usato con successo questo per distribuire più file WAR con un insieme comune di risorse (ad esempio, una versione compressa di Dojo).

Per esempio, un orecchio può apparire come:

ear-file/proj1 
ear-file/proj2 
ear-file/config 
ear-file/lib 
ear-file/resources 
ear-file/META-INF 
ear-file/APP-INF 

Si consiglia inoltre di leggere sul filo .war vs .ear file da un post StackOverflow precedente.

Answer 4

Io non sono eccessivamente familiarità con Struts (o Spring MVC, è per questo), ma si potrebbe guardare il SpringSource dm Server. Si basa su Equinox, il contenitore OSGi utilizzato da Eclipse e un Apache Tomcat bundlized (oltre a quello di Spring framework).

Con il server SpringSource, ogni file di guerra viene distribuito più o meno tradizionalmente, ma può accedere alle risorse (classi, servizi, ecc.) Tramite i normali meccanismi OSGi. Questi meccanismi sono basati sui classloader del bundle OSGi, che potrebbero essere problematici per la condivisione di risorse di file come jsps, html, css e così via. Potrebbe funzionare se tu avessi qualcosa di simile a DefaultServlet che ha reso le cose dal classloader piuttosto che dal file system. (O, diamine, potrei renderlo più complicato di quanto necessario.)

D'altra parte, è possibile distribuire tutto come applicazioni Web indipendenti e collegarle tutte insieme al client.

La prima risposta alla domanda the modular web apps sembra davvero interessante, anche se non direttamente applicabile al server SpringSource, poiché non fornisce HttpService OSGi. Credo che le recenti specifiche aziendali OSGi 4.2 si stiano dirigendo verso l'approccio del deploy-war-files-as-OSGi-bundles del server SpringSource.

In risposta alla tua EDIT 2 domanda , se ho capito bene, il "contesto web" in quel answer sarebbe stata costruita in modo dinamico utilizzando il HTTPService, che è un'interfaccia che fornisce i metodi per

1. servlet registrare sotto URL e

2. risorse (file di registro, ecc) sotto gli URL.

Poiché tali operazioni sono gestite dinamicamente, non ci sarebbe bisogno di nulla che unisse esplicitamente bit di contesto web.