In questa prima puntata parleremo delle caratteristiche principali del prodotto, della nuova architettura, delle procedure di avvio, e della configurazione dei principali componenti del server.
Introduzione
JBoss 7 application server è un prodotto sul mercato da ormai diverso tempo e, sebbene si trovi in rete già molta documentazione, specialmente sul sito di JBoss.org, abbiamo voluto ritardare questa presentazione nell’attesa di sperimentare con mano quanto descritto sui vari turorial ufficiali, confrontando l’esperienza con quanto si trova in rete (blog, tutorial, forum etc.).
Una delle caratteristiche infatti che da sempre contraddistingue in negativo i prodotti di JBoss, i quali sono peraltro sempre di ottimo livello da un punto di vista tecnico, è la carenza di informazioni certe, complete e facilmente reperibili: a volte navigare i vari siti della casa americana è già un’impresa di per se’. La versione 7 ha segnato in questo senso un piccolo miglioramento, dato che adesso anche la documentazione e la relativa affidabilità delle informazioni che si trovano in rete sono notevolmente migliorate.
In questa prima puntata parleremo delle caratteristiche principali del prodotto, della nuova architettura, di quali siano le procedure da seguire per “accendere” il server, nonche’ per la configurazione di più importanti componenti del server (console web, connessioni al database, logging, etc). Nei prossimi articoli parleremo invece delle procedure di impacchettamento e deploy delle applicazioni, di classloading delle librerie e delle applicazioni e della gestione dei moduli e dei servizi.
Lo scopo degli articoli, come è d’abitudine per MokaByte, non è quello di pubblicare una completa e omnicomprensiva guida a JBoss7, per la quale rimandiamo alle tonnellate di documentazione che si possono trovare in rete, ma piuttosto di realizzare una sintesi di quello che, durante l’attività di sviluppo su progetti, abbiamo trovato utile, interessante, corretto. Per ulteriori approfondimenti rimandiamo ai riferimenti riportati nella parte conclusiva dell’articolo, dove sono riportati anche i link alla documentazione ufficiale, dalla quale abbiamo ripreso la maggior parte delle informazioni qui riportate.
Download e installazione
Come per le versioni precedenti, l’installazione del pacchetto è una procedura molto semplice dato che si riduce al download del bundle che si vuole utilizzare; al momento in cui scrivo questo articolo, l’ultima versione disponibile è la 7.1.1 Brontes (7.1.1.Final) che è Certified Java EE 6 Full Profile. Una volta scaricato lo ZIP è sufficiente scompattare l’archivio in una cartella e posizionarsi nella directory di lavoro per configurarlo e lanciarlo (vedi oltre).
Panoramica su JBoss 7
La prima cosa che salta agli occhi con il nuovo JBoss è la nuova architettura dell’application server, architettura che è stata completamente rivista, e che porta per gli utilizzatori due importanti conseguenze: la prima riguarda le prestazioni che sono veramente strabilianti almeno per quanto concerne il tempo di avvio ridotto veramente a pochi secondi. Seppure non sia ancora in possesso di benchmark rigorosi, a livello empirico anche i tempi di risposta delle applicazioni sotto stress paiono interessanti, e magari ne riparleremo più a fondo in uno dei prossimi articoli. L’altra importante conseguenza di questa nuova organizzazione riguarda il modo con cui adesso è possibile non solo configurare i vari servizi ma anche la modalità di esercizio.
Le configurazioni di run nella versione 6
Fino alla versione 6, infatti, era possibile scegliere o personalizzare una delle configurazioni (o crearne di nuove partendo da quelle disponibili) di run: nella installazione base erano disponibili sotto la cartella server diverse sottocartelle che rappresentavano ognuna una differente configurazione di esercizio. Il concetto base è che, presa una determinata configurazione, quello che è presente al suo interno, sotto forma di cartelle, librerie, file di configurazione, viene utilizzato o attivato come servizio. Per questo in JBoss 6 potevamo avere la configurazione minimal, default, all che si differenziavano per il numero di servizi da attivare: per esempio la minimal non fa partire il container web, mentre il servizio di clustering si ha solo nella all.
Per far partire il server tramite il flag “-c” si poteva scegliere quella che si voleva mandare in esecuzione. Per esempio con
JBOSS_HOME/bin/run.sh -c mokabyte
possiamo far partire il jboss configurato per far funzionare i vari servizi e applicazioni su cui gira il nostro sito.
Le nuove modalità della versione 7
Con JBoss 7, le cose sono state completamente riviste, dato che adesso il server prevede la possibilità di essere mandato in esecuzione in modalità standalone e multidomain (vedi oltre) e di conseguenza l’organizzazione delle directory è stata rivista in funzione di questa nuova funzionalità, come raffigurato nella figura 1
Figura 1 – La nuova organizzazione delle directory.
Le sottocartelle della directory radice
Nei paragrafi che seguono riportiamo nel dettaglio il nome delle sottocartelle in cui è suddivisa la directory radice (d’ora in poi JBOSS_HOME), corredate di una adeguata spiegazione:
bin
La directory bin contiene gli script di avvio e i file di configurazione per l’avvio per gli ambienti Unix e Windows.
bundles
Questa è la collocazione dei bundle OSGi.
docs/schema
È la sottocartella per i file di definizione degli schema XML.
domain
File di configurazione, contenuto di cui fare il deploy, aree scrivibili usate dai processi nella modalità domain eseguiti a partire da questa installazione.
modules
AS 7 è basato su una architettura modulare del classloader. I vari moduli usati nel server sono immagazzinati qui.
standalone
File di configurazione, contenuto di cui fare il deploy, aree scrivibili usate dal server in modalità singola standalone eseguiti a partire da questa installazione.
welcome-content
Il contenuto di default della pagina di benvenuto.
Questa nuova organizzazione (standalone vs multidomain) permette di mandare in esecuzione l’application server in funzione delle proprie esigenze, separando il caso in cui sia necessario eseguire un solo server da quello in cui si voglia far eseguire una batteria di server centralizzando la parte di configurazione e gestione.
Le due modalità di esecuzione infatti non differiscono per le funzionalità e per i servizi che mettono a disposizione, ma piuttosto per la modalità con la quale possono essere gestiti: per esempio una batteria di server appartenenti allo stesso domain potrà essere gestita in maniera unificata tramite la console, e i server potranno essere accesi o spenti all’unisono o si potrà effettuare il deploy di applicazioni in modo coerente con una procedura semplice e unificata.
Struttura della directory “standalone”
Se si sceglie la modalità standalone, l’application server viene mandato in esecuzione come un processo isolato e indipendente in modo del tutto simile a quanto avveniva per le versioni precedenti. I file di configurazione, le aree di deploy e le librerie di lavoro sono posizionate nelle sottocartelle della JBOSS_HOME/standalone secondo l’organizzazione in directory riportata nei paragrafi seguenti.
configuration
Contiene i file di configurazione per la installazione standalone. Tutti i parametri di lavoro sono raggruppati in questa collocazione.
data
Area dove sono rese persistenti tutte le informazioni necessarie per mantenere uno stato consistente fra i vari restart del server.
deployments
Come per le versioni precedenti, in questa sottocartella devono essere copiati i pacchetti e i servizi di cui si desidera effettuare il deploy; la directory è monitorata in modo automatico. Da notare che in produzione si consiglia l’uso della console o della API per eseguire il deploy, mentre durante lo sviluppo si potrà continuare a usare la copia manuale. A differenza delle versioni precedenti, durante il ciclo di vita del deploy di una applicazione (p.e. MyApp.ear), l’application server copia dei tag file in modo da evidenziare lo stato di avanzamento del deploy (p.e.: MyApp.ear.deployng, MyApp.ear.deployed, MyApp.ear.undeployed, MyApp.ear.error).
lib/ext
Collocazione in cui copiare le varie librerie referenziate dalle varie applicazioni secondo il modello Location Extension-List (ne parleremo in un prossimo articolo).
log
Contiene i file di log.
tmp
Contiene file temporanei ad uso dell’application server durante il suo funzionamento.
Configurazione “domain”
Come abbiamo avuto modo di accennare in precedenza, quando si manda in esecuzione l’application server in modalità domain, si ha la possibilità di gestire istanze multiple di server da un solo punto di controllo. JBoss definisce una collezione di server differenti come un “dominio” o domain, definizione non nuova ma di fatto migrata dalla vecchia architettura e organizzazione a cluster, che può essere configurato per essere eseguito su diverse macchine (fisiche o virtuali). Tutte le istanze in esecuzione sui vari host possono essere gestite centralmente per mezzo di un Domain Controller che interagisce con i vari Host Controller. In uno dei prossimi articoli avremo modo di approfondire questi aspetti. Per il momento ci limitiamo a riportare l’attuale organizzazione delle directory per la configurazione a domini (cartella JBOSS_HOME/domain) con la descrizione delle varie sottocartelle.
configuration
Come per il caso Standalone. Fino a che non si modifica uno dei parametri con la console di domain, l’AS parte con la configurazione caricata da questa collocazione. Ne parleremo in un prossimo articolo.
content
Dato che in modalità Domain l’application server non permette il deploy di applicazioni tramite la semplice copia a caldo, ma solo tramite console, in questa sottocartella l’application server archivia le applicazioni e i moduli installati.
lib/ext
Come per il caso Standalone.
log
Collocazione dove lo Host Controller scrive i suoi log. Anche il Process Controller (applicazione che controlla l’Host Controller e ogni altro Application Server) scrive i log in questo punto.
servers
Area sotto il controllo di ogni istanza di Application Server che viene mandata in esecuzione a partire da questa installazione. Ogni istanza di Application Server avrà una sua sottocartella, creata al momento in cui viene fatta partire. Qui sotto troveremo le sottocartelle data, log e tmp il cui significato è analogo al caso Standalone.
Configurazioni di JBoss Application Server 7
Per quanto concerne i vari file di configurazione e gli effetti sui diversi servizi, la modalità di intervento è piuttosto simile nei due casi standalone o domain.
Nel primo caso (standalone), i file di configurazione su cui intervenire sono quelli riportati di seguito.
standalone.xml (default)
File relativo al profilo “Java Enterprise Edition 6 certified web profile”; contiene la configurazione relativa alle tecnologie incluse nella specifica Web Profile, più Java Connector 1.6 Architecture, Java XML API for RESTFul Web Services e OSGi.
standalone-preview.xml
File relativo al profilo “Java Enterprise Edition 6 full profile preview”, contiene la configurazione relativa alle tecnologie incluse in questa configurazione, con l’aggiunta delle technology previews della Java API for XML-Based Web Services (JAX-WS) 2.2 e della Java Message Service 1.1.
standalone-ha.xml
File per la configurazione del profilo di default con le funzionalità clustering.
standalone-preview-ha.xml
File per la configurazione del profilo “Java EE 6 full preview” con funzionalità di clustering.
Da notare che nel file di configurazione del server
JBOSS_HOME/standalone/configuration/standalone.xml
è definita la configurazione dell’AS standalone e tale file viene “storicizzato” dall’Application Server, mantenendo più copie nascoste del file. Occorre quindi prestare molta attenzione a modificarlo manualmente quando il server è attivo perche’ si rischia di vedere sovrascritto quel file al successivo riavvio dell’AS, perdendo le configurazioni apportate a mano (l’argomento è descritto meglio nella documentazione ufficiale).
Analogamente, per la modalità domain, i file da tenere sotto controllo sono i seguenti:
domain.xml (default)
File relativo al profilo “Java Enterprise Edition 6 certified web profile”; contiene la configurazione relativa alle tecnologie incluse nella “Web Profile specification”, più Java Connector 1.6 Architecture, Java XML API for RESTFul Web Services e OSGi.
domain-preview.xml
File che contiene la configurazione di default più il supporto per le preview della JAX-WS e della Java Message Service.
Va notato inoltre che i file *-preview.xml sono disponibili solamente con la distribuzione “Full Profile preview”.
Accendere i motori: come far partire l’application server
Per avviare l’application server in modalità default (sia standalone che domain) è sufficiente eseguire lo script con il nome corrispondente: nel primo caso, dalla cartella $JBOSS_HOME/bin si potrà eseguire
./standalone.sh
mentre, analogamente, per la versione domain, si potrà scrivere
./domain.sh
Ovviamente i nomi degli script sono riferiti a piattaforma Unix; su Windows si dovranno eseguire i corrispondenti .bat, ma il concetto non cambia.
Nel caso si volesse cambiare configurazione, in modo analogo a quanto accadeva con le versioni precedenti, dove però si poteva specificare la configuration indicando il nome della corrispondente cartella, è possibile specificare allo script di run il nome del file di configurazione utilizzando l’argomento –server.
Nel caso si volesse usare la configurazione “JavaEE 6 preview”, ad esempio, si potrebbe usare la seguente sintassi per la standalone
./standalone.sh --server-config=standalone-preview.xml
o, analogamente, per la domain, il seguente comando
./domain.sh --domain-config=domain-preview.xml
Se non si verificano problemi particolari in fase di avvio, si potrà verificare il funzionamento collegandosi alla “welcome page” disponibile all’indirizzo http://localhost:8080
Figura 2 – La pagina di benvenuto dell’application server, da cui si può accedere alla console di amministrazione.
Come si può notare, da questa pagina è possibile accedere alla console di amminstrazione web, che permette di configurare l’application server in molti aspetti: configurare una sorgente dati, o il deploy di applicazioni etc.. L’indirizzo della console è http://nome_host:9090/console dove il numero della porta può essere specificato nella parte http-interface all’interno del file di configurazione.
Il funzionamento della console web risulta piuttosto intuitivo e non presenta aspetti degni di nota in questo articolo, per cui concentreremo l’attenzione sull’altro strumento di configurazione e amministrazione, ossia la Command Line Interface (CLI).
Interfaccia a linea di comando (CLI)
JBoss 7 mette a disposizione un ampio set di comandi per gestire l’application server direttamente da linea di comando, opzione questa particolarmente comoda nel caso di un server in produzione per il quale usualmente la console web non è raggiungibile, per motivi di sicurezza o più semplicemente per come è organizzata la topologia della rete. La Command Line Interface (CLI) è inoltre comoda anche per implementare sequenze di comandi in batch (si veda oltre).
La console testuale è accessibile direttamente tramite lo script jboss-cli.sh disponibile nella directory $JBOSS_HOME/bin; per esempio
./jboss-cli.sh --connect Connected to standalone controller at localhost:9999
Attenzione a un fatto molto importante: nella versione 7.0.x lo script per eseguire la CLI è il jboss-admin.sh, che è stato rinominato in jboss-cli.sh nelle versioni sucessive, ossia anche quella a cui facciamo riferimento in questa serie di articoli.
Uno sguardo ai comandi
Una volta connessi si potranno eseguire una serie di comandi per gestire il server; in tal caso il comando help potrà fornire un primo e rapido aiuto. Di seguito analizzeremo i comandi più utili e importanti; per un elenco completo si rimanda alla documentazione ufficiale.
Se non si specifica il parametro –connect, di fatto la CLI viene eseguita in modalità interattiva, senza connettersi ad alcun server. Ecco una tipica sequenza di comandi che si possono utilizzare in questo caso:
./bin/jboss-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] [disconnected /] connect Connected to domain controller at localhost:9999 [domain@localhost:9999 /] quit Closed connection to localhost:9999
Se non si specificano host e porta, si assume di connettersi all’host locale sulla porta 9999, che è quella dove per default si attiva la console di amministrazione: tale parametro viene specificato nel file di configurazione standalone.xml (o equivalenti, vedi quanto detto prima), nella sezione , dove si potranno variare anche i valori di configurazione dei vari connettori HTTP e HTTPS. Ecco un esempio:
port-offset="${jboss.socket.binding.port-offset:0}"> port="${jboss.management.native.port:9999}"/> port="${jboss.management.http.port:9990}"/> port="${jboss.management.https.port:9443}"/>
Volendo specificare nome host e porta si dovrà usare il parametro –controller, come ad esempio
./jboss-cli.sh --connect --controller=localhost:9998
oppure, in modalità interattiva, specificarlo in un secondo momento:
./bin/jboss-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server [disconnected /] connect 192.168.0.10:9999 Connected to standalone controller at 192.168.0.1:9999
Il nome host su cui il server è in ascolto viene specificato nel file di configurazione, come si è avuto modo di vedere in precedenza. Per ottenere l’elenco completo dei comandi, oltre a far riferimento alla documentazione ufficiale, si può usare il comando help:
[domain@localhost:9999 /] help Supported commands: cn (or cd) - change the current node path to the argument; connect - connect to the specified host and port; deploy - deploy an application; help (or h) - print this message; history - print or disable/enable/clear the history expansion. ls - list the contents of the node path; pwn (or pwd) - prints the current working node; quit (or q) - quit the command line interface; undeploy - undeploy an application; version - prints the version and environment information. add-jms-queue - creates a new JMS queue remove-jms-queue - removes an existing JMS queue add-jms-topic - creates a new JMS topic remove-jms-topic - removes an existing JMS topic add-jms-cf - creates a new JMS connection factory remove-jms-cf - removes an existing JMS connection factory data-source - allows to add new, modify and remove existing data sources xa-data-source - allows to add new, modify and remove existing XA data sources For a more detailed description of a specific command, execute the command with '--help' as the argument.
Da notare fra i vari comandi alcuni che sono detti operation requests (per esempio create-jms-queue, oppure data-source), ossia comandi che permettono di interagire con il management model e che permettono di modificare la configurazione leggendo e modificando i file di configurazione XML come se si stesse utilizzando un editor testuale.
Una operation request consiste essenzialmente di tre parti:
- la destinazione su cui si vuole agire
- il nome dell’operazione
- un set opzionale di parametri.
Ecco la definizione formale:
[/node-type=node-name (/node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]
Immaginando l’ambiente di configurazione organizzato come un albero, ossia un configuration tree, con il file XML a rappresentarne in modo preciso il mapping testuale, la destinazione indica la porzione di tale albero (node-type) su cui si vuole agire: potrebbe essere la sezione dedicata ai connettori JCA, o al logging, o a un qualche profilo di esecuzione in produzione.
Per maggiori approfondimenti sull’uso degli operation requests, si rimanda alla documentazione ufficiale, visto che una trattazione completa in questa sede andrebbe oltre gli scopi di questo articolo.
La GUI della CLI (un po’ come “la brum del mmh ha un pfff nella umm”)
Nel momento in cui si manda in esecuzione la CLI, specificando il parametro –gui, si può attivare la versione a console grafica: di fatto non è molto utile se il server è remoto, e in tal caso è meglio optare per la versione web.
Figura 3 – La console a interfaccia grafica della CLI.
Passare alla modalità GUI può essere comunque utile per consultare lo stato delle varie variabili o più generalmente la struttura completa del configuration tree. Tutti i comandi immessi da CLI sono mantenuti in una history, che è attiva per default, mantenuta sia in memoria che su file, in modo da conservare la sequenza fra una sessione e un’altra. Il file si chiama .jboss-cli-history e viene salvato nella home directory utente. È disponibile il comando history per attivare (history enable), disattivare (history disable) e cancellare (history clear) la storia dei comandi. Senza parametri, fornisce l’elenco degli ultimi comandi eseguiti.
Esecuzione in Batch Processing
La modalità batch permette di raggruppare ed eseguire una serie di comandi come se fossero una sola unità atomica: analogamente alle transazioni su un database, se uno solo dei comandi fallisce, tutti i comandi già eseguiti con successo verranno annullati (rollback). Solo i comandi associabili a delle operation request possono essere inseriti in un batch (per esempio i comandi cd, ls, help, etc. non sono inseribili).
La modalità batch si attiva con il comando batch; per esempio:
[standalone@localhost:9999 /] batch [standalone@localhost:9999 / #] /subsystem=datasources/data- source="java:/H2DS":enable [standalone@localhost:9999 / #] /subsystem=messaging/jms-queue="newQueue":add
Per eseguire un batch si usa il comando run-batch:
[standalone@localhost:9999 / #] run-batch The batch executed successfully.
Per uscire dalla modalità senza perdere il batch definito:
[standalone@localhost:9999 / #] holdback-batch [standalone@localhost:9999 /]
Per riattivare nuovamente il batch:
[standalone@localhost:9999 /] batch Re-activated batch #1 /subsystem=datasources/data-source=java:/H2DS:/H2DS:enable
Sono disponibili i seguenti comandi per interagire con un batch:
clear-batch edit-batch-line (e.g. edit-batch line 3 create-jms-topic name=mytopic) remove-batch-line (e.g. remove-batch-line 3) move-batch-line (e.g. move-batch-line 3 1) discard-batch
La JConsole
A fianco della CLI (testuale o grafica) è disponibile la JConsole, tramite la quale è possibile verificare lo stato di salute dell’application server, la memoria occupata, lo stato delle applicazioni. Per il momento tralasciamo questa funzionalità.
Configurazione di una DataSource
Una datasource può essere configurata in due modi: come modulo (as a module) o tramite deploy.La procedura as a module (di fatto definita tramite file XML) permette di definire il driver e la connessione a livello di dominio, cosa particolarmente utile in ambiente di produzione qualora si lavori in modalità domain; in aggiunta, non ci sono le limitazioni della modalità deployment (vedi oltre) per cui anche se si opta per la modalità standalone, questa procedura è comunque comoda.
Durante la fase di sviluppo di applicazioni (dove start-stop, hot deploy e redeploy di DS possono essere frequenti) probabilmente la procedura as-a-deploy può risultare più comoda. Il deploy per copia si riduce alla semplice copia del driver e della datasource all’interno della directory di deploy, o equivalentemente usando le istruzioni a linea di comando della CLI. Questa modalità presenta alcune piccole limitazioni che, sebbene siano non eccessivamente penalizzanti durante il processo di sviluppo del codice, possono esserlo decisamente in produzione. Per poter aggiungere una sorgente dati JDBC infatti, la prima cosa che si deve fare è configurare un driver JDBC, che viene quindi associato a un nome univoco: nel caso dell’hot deploy per copia, tale nome viene ricavato dal nome del file .jar cosa che in alcuni casi può rappresentare una limitazione. Questo succede ad esempio se il driver è composto da più file, come nel caso di Oracle che separa la parte driver dalla parte di librerie di supporto per charset e internazionalizzazione. Altro limite è dato alla obbligatorietà di utilizzare driver di tipo JDBC 4 dato che il modulo deployer di JBoss cerca dentro il .jar le meta informazioni contenute nei file XML descrittori che si trovano nella cartella META-INF.
Se si esegue il deploy tramite la copia (copiare il JAR nella cartella $JBOSS_HOME/standalone/deployments) si potrebbe ricevere un output di questo tipo:
12:59:17,663 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "mysql-connector-java-5.1.15.jar" 12:59:18,191 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) Deploying non-JDBC-compliant driver class com.mysql.jdbc.Driver (version 5.1) 12:59:18,291 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "mysql-connector-java-5.1.15.jar"
Se invece si desidera usare la CLI, si potranno utilizzare i seguenti comandi (qui l’output è riferito al server in esecuzione in modalità standalone)
[standalone@localhost:9999 /] connect Closed connection to localhost:9999 Connected to standalone controller at localhost:9999 [standalone@localhost:9999 /] deploy /dev/java/drivers/mysql-connector-java-5.1.15.jar 'mysql-connector-java-5.1.15.jar' deployed successfully.
Deploy di un driver tramite modulo
La modalità alternativa al deploy per copia, si basa sulla definizione di un modulo che fornisca le classi necessarie a definire un driver a livello di dominio. Il vantaggio principale è dato dalla possibilità di definire la sorgente dati in modo semplice e centralizzato: per esempio definire la sorgente all’interno del file domain.xml semplifica non di poco i compiti dell’amministratore che può in questo modo focalizzare il suo lavoro dal punto di vista del dominio e di gruppi di server piuttosto che sul singolo server.
Il processo per la creazione di un modulo è piuttosto semplice e si compone di 4 semplici passi:
- creare la struttura delle directory;
- creare un file module.xml per le dipendenze;
- aggiungere il driver alla configurazione di esercizio;
- usare il driver per configurare una nuova connessione datasource.
Struttura directory
Per prima cosa è necessario creare la struttura delle directory dedicate al modulo. Per esempio nel caso si voglia creare un modulo per il driver di MySQL si dovrebbe procedere nel seguente modo:
cd $JBOSS_HOME mkdir modules/com/mysql mkdir modules/com/mysql/jdbc mkdir modules/com/mysql/jdbc/main
Copiare il o i file relativi al driver nella directory appena creata;
Creare il file module.xml
Si crei a questo punto un file module.xml col quale verranno definite le dipendenze e le risorse necessarie; nel nostro caso:
Aggiungere il driver alla configurazione
Si deve procedere a questo punto ad aggiungere il driver alla configurazione domain o standalone; questo può essere fatto editando uno dei due file standalone.xml o domain.xml, in modo da aggiungere l’elemento relativo al driver nella sotto sezione relativa ai datasource:
[...] enabled="true" use-java-context="true" pool-name="H2DS"> jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 h2 sa sa org.h2.jdbcx.JdbcDataSource com.mysql.jdbc.jdbc2.optional.MysqlXADataSource [...]
A tal punto li si può aggiungere alla configurazione di esercizio tramite il comando jboss-admin.sh della CLI; il comando è il seguente:
/subsystem=datasources/jdbc-driver=mysql:add(driver-name="mysql", driver-module-name="com.mysql.jdbc", driver-xa-datasource-class-name ="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource")
Usare il driver per configurare la connessione
Adesso è possibile usare il driver per configurare una nuova connessione datasource. Nel caso in cui si usi un driver non JDBC-4 compliant è necessario specificare la classe del driver tramite il tag all’interno della sezione nel file standalone.xml o domain xml.
Eventualmente si tenga presente che, come per le versioni precedenti, l’application server fornice una datasource di default già pre-configurata la quale si basa sul database embedded H2 database, utile per lo sviluppo rapido di prove e prototipi.
Per chi fosse interessato, l’application server fornisce con la installazione standard una configurazione per il database H2 configurato come modulo, la cui definizione è presente all’interno della directory $JBOSS_HOME/modules/com/h2database/h2; eccone un esempio:
jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 h2 10 20 true sa sa pool-name="ExampleXADS"> h2 name="URL">jdbc:h2:mem:test 10 20 true sa sa org.h2.jdbcx.JdbcDataSource
Conclusioni
Si conclude qui questa prima puntata della serie dedicata a JBoss 7. Per adesso abbiamo visto alcuni aspetti preliminari necessari per poter comprendere come installare e configurare il server. Dal mese prossimo parleremo di alcuni concetti “core”, primi fra tutti quelli relativi al caricamento delle classi e alla definizione dei vari classpath.
Riferimenti
[1] JBoss Getting Started Guide (download e avvio di JBoss Application Server 7)
https://docs.jboss.org/author/display/AS7/Getting+Started+Guide
[2] JBoss Getting Started Developing Applications Guide (primi passi nello sviluppo e deploy di una applicazione Java EE per JBoss 7)
https://docs.jboss.org/author/display/AS7/Getting+Started+Developing+Applications+Guide
[3] JBoss JavaEE 6 Tutorial (guida Java EE 6 di casa JBoss)
https://docs.jboss.org/author/display/AS7/JavaEE+6+Tutorial
[4] JBoss Admin Guide (configurazione e gestione dell’application server)
https://docs.jboss.org/author/display/AS7/Admin+Guide
[5] JBoss Developer Guide (concetti base di cui tener conto durante lo sviluppo di applicazioni per JBoss Application Server 7, con approfondimenti sul classloading)
https://docs.jboss.org/author/display/AS7/Developer+Guide
[6] JBoss7 HA Guide
https://docs.jboss.org/author/display/AS7/High+Availability+Guide
[7] Extending JBoss AS 7
https://docs.jboss.org/author/display/AS7/Extending+JBoss+AS+7
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.