Componenti dell'interfaccia utente innestabili nelle applicazioni Web Java

if my above observation is correct

Dipende. Puoi anche includere tutto nella distribuzione e configurare solo ciascuna installazione per utilizzare ciò di cui ha bisogno. I possibili motivi per utilizzare i plugin sono:

1. I plug-in vengono addebitati separatamente e non si desidera distribuire gratuitamente le funzionalità
2. I tuoi plugin sono "pesanti" in qualche modo, ad es. ce ne sono molti o hanno una dimensione significativa.

Se tali motivi non si applicano al tuo caso, potresti pensare a una soluzione più semplice.

how to have above kind of plugin structure with Java/Java EE?

Se stai lavorando con la soluzione più semplice, ecco lo schema generale:

1. Nella configurazione dell'app (che può essere il file * .properties o un record nel DB, a seconda di quale funzione funzioni meglio per i tuoi utenti, perché dovrebbero essere in grado di modificarlo), aggiungi una proprietà che contiene un percorso della directory dei plug-in
2. Definisci ed esporti API plugin - un insieme di interfacce che un plug-in deve implementare per consentire all'applicazione di richiamare questo plug-in
3. Scrivi personalizzato ClassLoader che usa la proprietà dal n. 1 e forse controlla se ciascun plugin implementa correttamente la tua API
4. Carica le classi e le risorse dei plug-in utilizzando questo programma di caricamento classi
5. Richiama le funzioni dei plug-in tramite le interfacce dell'API del plug-in o, se il plug-in è composto solo da risorse, includi quelle necessarie,

are there any frameworks in Java that supports above kind of thing?

Sì. Googling per "java plugin framework" ne rivela alcuni.

Altre domande sull'argomento:

• Il modo migliore per creare un sistema Plugin con Java
• Scelta del framework dei plug-in Java
• Come creare un programma Java plug-in?
• Architettura "plug-in" di applicazioni Web Java

Aggiornamento:

Per caricare i file JSP (o qualsiasi file), usa il classloader come descritto sopra: vedi getResource e getResourceAsStream metodi.

Aggiornamento 2:

Dopo aver meditato ancora un po ', vedo che devi solo includere condizionalmente un JSP in un altro JSP. Questo non è "componenti UI collegabili" o qualcosa del genere, è solo inclusione condizionale. Non ci sono quadri per questo dato che si tratta di circa 4-6 linee di codice. Sembra che tu pensi che sia più complesso di quanto non sia in realtà.

Penso che ciò accada:

• ha una proprietà in un file (o in DB) che indica quale plugin dovrebbe essere usato
• assegna un valore di questa proprietà a una variabile, ad esempio String plugin = ...
• passalo al tuo JSP: request.setAttribute("plugin", plugin); o qualcosa di simile
• usalo come <jsp:include page="${plugin}" flush="true" />

Potrebbe essere sbagliato nella sintassi, ma il punto dovrebbe essere chiaro. Spero che ti aiuti.

Ecco una possibile soluzione. Ce ne sono altri, ma questo mi sembra un modo abbastanza semplice per farlo. Presumo che il tuo sito verrà costruito utilizzando un'architettura MVC e che i plug-in forniscano tre tipi di contenuti: classi Java per implementare controller, viste JSP e file di risorse statiche che devono essere pubblicati.

• Distribuisci la tua applicazione come una struttura di directory espansa piuttosto che un file WAR. Ciò significa che gli utenti saranno in grado di rilasciare i plugin come file JAR nella directory WEB-INF/lib . Il server aggiungerà automaticamente qualsiasi percorso JAR distribuito in questa directory al classpath.
• Utilizza il framework Spring MVC e abilita le sue opzioni per analizzare il classpath per i componenti.
• Ogni plugin può avere una o più classi con l'annotazione Spring @Component , che farà in modo che Spring crei automaticamente delle istanze. Potrebbero usare @PostConstruct su un metodo per far eseguire tale metodo all'avvio, che può essere utilizzato per qualsiasi inizializzazione richiesta.
• L'integrazione con il resto del sito può essere ottenuta esportando servizi come oggetti di tipo noto e utilizzando le annotazioni @Autowire sui campi di quel tipo per far sì che Spring fornisca riferimenti ad essi.
• Utilizza la tecnica descritta al link per configurare un gestore di risorse che associa un nome di directory sul server a una directory nel classpath e memorizza le risorse statiche nel file jar in quella posizione
• Precompila i tuoi file JSP in classi Java e includili nel tuo file jar (istruzioni qui: link )

Dovresti quindi essere in grado di raggruppare le funzionalità del tuo sito web in file JAR che possono essere distribuiti semplicemente copiando il file JAR nella directory WEB-INF/lib della tua app web.

Se si può usare la struttura dei file per configurare abilitato o meno dipende da come si distribuisce la propria applicazione web.

L'app Web verrà distribuita sul server dei clienti? Quindi puoi usare la struttura dei file. Distribuirai l'app Web sul tuo server? Quindi non sarai in grado di utilizzare la struttura dei file.

In ogni caso è probabilmente meno complicato includere tutte le viste (ad esempio pagine JSP o JSF) e quindi avere una tabella di configurazione nel database per ciascun cliente che indichi quali plug-in sono abilitati. Quindi nella visualizzazione (JSP o JSF) si utilizza il rendering condizionale in base a tali valori di configurazione.

In altre parole in JavaEE generi dinamicamente html, quindi per ogni metodo di pagamento puoi controllare nel tuo database se è abilitato e quindi rendere solo quelli abilitati al tuo output html finale.

Aggiornamento: Un modo per avere build diverse in cui includere / escludere il codice potrebbe essere quello di utilizzare Maven e impostare diversi profili per le diverse opzioni di pagamento. Questa soluzione funziona solo se si distribuisce la propria webapp sui server dei clienti. Continuo a pensare che la soluzione più pulita sarebbe usare la configurazione.