Questo tutorial mostra come è possibile personalizzare una installazione di JBoss EAP 6 / WildFly in modalità di dominio utilizzando le System Property dell’application server.
Il presupposto di una configurazione in modalità dominio è che si prevede di organizzare un gruppo omogeneo di server, raggruppati per Server Groups e associati a uno specifico profilo. I servers appartenenti al dominio sono controllati da un server di amministrazione chiamato Domain Controller.
Malgrado l’omogeneità dei servers dello stesso Server Group, è abbastanza frequente che i server del dominio richiedano una o più specifiche impostazioni. Ad esempio, potrebbe essere necessario configurare ogni server del dominio con un puntamento ad un datasource diverso. Un altro requisito comune potrebbe essere quello di utilizzare delle porte predeterminate per alcuni servizi, come quello HTTP. Vediamo come realizzare entrambi gli esempi.
Esempio 1: puntamento a diversi datasources
Abbiamo la seguente definizione di origine dati in nostro dominio:
${connection-url} mysql mysql mysql
Come evidenziato nella porzione di codice superiore, la connection URL del datasource MySQLDS è impostata in base al valore di una property. Come definire il valore della property? Il modo più specifico di farlo è di definirlo a livello dei singoli servers del dominio (nel file host.xml):
...
Le proprietà possono essere definite anche a livello di Host Controller (sempre nel file host.xml), che comporta che la proprietà sarà condivisa da tutti i servers che sono controllati dall’Host Controller:
...
E’ possibile inoltre configurare una System Property anche a livello di Server Group (nel file domain.xml), che comporta la visibilità della Property tra tutti i servers legati a quel gruppo:
...
Per completezza aggiungiamo che è possibile impostare una System Property anche a livello di dominio (nel file domain.xml). Esempio:
... ...
Lo scopo del parametro boot-time=true è quello di garantire il settaggio della Property al momento del lancio della JVM (equivalente ad impostare la Property con il parametro -D), senza aspettare che vengano avviati i servizi amministrativi dell’application server.
Con tutte queste possibili scelte, può accadere che una Property sia definita a più livelli. In questo caso, quale sarà effettivamente utilizzata all’interno della configurazione o dalle applicazioni? La regola è che la configurazione più specifica prevale su quella che è più generica. Così le Property a livello di Server sovrascrivono eventuali Property definite a qualunque altro livello, le Property a livello di Host sostituiscono quelle a livello di Server Group e così via. La figura seguente illustra l’ordine di precedenza quando una proprietà è definita a più livelli:
Esempio 2: diverse porte HTTP
Un altro scenario comune è quello di fornire una porta specifica su ogni server del dominio. È possibile farlo automaticamente utilizzando l’attributo port-offset dei singoli servers; tuttavia questo richiede che tutti i servizi scalino dello stesso offset per ogni server. Se invece volessimo utilizzare, accanto ad un offset di 100 unità per ogni server, delle porte specifiche per l’HTTP, come ad esempio la porta 8888 per il primo server e la 8889 per secondo server?
Per realizzare questa configurazione è sufficiente impostare nei socket-binding (nel file domain.xml) per il servizio HTTP il valore della porta come System Property e valorizzare l’attributo fixed-port a true:
...
Il valore della porta sarà definito a livello dei singoli server, come nel seguente esempio tratto dal file host.xml della configurazione del Dominio:
Conclusioni
In questo tutorial abbiamo appreso come è possibile specializzare la configurazione del Dominio, laddove i singoli server che lo compongono abbiano dei settaggi non omogenei tra di loro. Fermo restando che, qualora le specificità dei singoli server siano particolarmente numerose, è consigliata la modalità standalone, dove ogni server ha la sua configurazione da gestire, ma la complessità del controllo del server è sicuramente minore.
