Nel precedente articolo di questa serie abbiamo introdotto Wildfly, la sua struttura, il framework di classloading che permette le sue ottime prestazioni. In questo articolo continuiamo a conoscere questo application server in alcuni dei suoi aspetti di configurazione e di gestione.

Introduzione alla configurazione di Wildfly

Wildfly è un application server modulare altamente configurabile. Possiamo decidere cosa caricare in memoria, quali features offrire e quali servizi esporre.

Wildfly offre due modalità di esecuzione: standalone e domain. La modalità di esecuzione standalone permette di eseguire Wildfly come una semplice singola istanza. La modalità domain invece, permette di definire uno o più insiemi di istanze di Wildfly e gestirle in modo centralizzato tramite l’attribuzione di un profilo di esecuzione a ciascuna istanza.

Configurazione ed esecuzione del server in modalità standalone

Nella directory JBOSS_HOME/standalone sono presenti diverse configurazioni standalone per Wildfly. Possiamo specificare il file di configurazione con cui eseguire Wilfly tramite la ben nota opzione -c:

C:UsersFrancescowildfly-8.0.0.Final in>standalone -c standalone-ha.xml
      Calling "C:UsersFrancescowildfly-8.0.0.Final instandalone.conf.bat"
      Setting JAVA property to "c:glassfish4jdk7 injava"
      ==========================================================================
        JBoss Bootstrap Environment
        JBOSS_HOME: "c:UsersFrancescowildfly-8.0.0.Final"
        JAVA: "c:glassfish4jdk7 injava"
        JAVA_OPTS: "-XX:+UseCompressedOops -Dprogram.name=standalone.bat 
                    -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true 
    -Djboss.modules.system.pkgs
                    =org.jboss.byteman -agentlib:jdwp=transport=dt_socket,address=8787,
     server=y,suspend=n"
      ==========================================================================
      
      Listening for transport dt_socket at address: 8787
      22:43:19,025 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
      22:43:21,390 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Final
      22:43:21,649 INFO  [org.jboss.as] (MSC service thread 1-7) JBAS015899: 
         WildFly 8.0.0.Final "WildFly" starting
      22:43:31,035 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: 
     Creating http management service using socket-binding 
           (management-http)
      ...
      22:43:31,310 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) 
         JBAS010260: Activating JGroups subsystem.
      ...
      22:43:34,945 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) 
      JBAS017519: Undertow AJP listener ajp listening on /127.0.0.1:8009
      22:43:35,120 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) 
      JBAS017519: Undertow HTTP listener default listening on 
      /127.0.0.1:8080
      22:43:35,475 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 56) 
      MODCLUSTER000001: Initializing mod_cluster version 1.3.0.Final
      22:43:35,536 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 56) 
      MODCLUSTER000032: Listening to proxy advertisements on 
      /224.0.1.105:23364
      ...

Come abbiamo visto nel precedente articolo, il file standalone.xml si articola nel seguente  insieme di elementi:

• extensions
• system-properties
• paths
• management
• profile
• interfaces
• socket-binding-group

Il tag indica i moduli che verranno caricati all’avvio di Wildfly. Il tag ci permette di definire le proprietà di sistema a cui accedere dalle nostre applicazioni. Il tag permette di specificare un percorso del nostro file system e associarlo  una  variabile. Soffermiamoci un attimo su gli ultimi elementi.

Il tag definisce un insieme di coppie nome/risorsa. Tramite il nome è possibile riferire alla risorsa associata. La risorsa è una risorsa di rete: un indirizzo IP, un nome host, oppure, un’interfaccia di rete. Analogamente, il tag socket-binding-group definisce un insieme di coppie nome/risorsa. Questa volta, la risorsa indica una porta logica.

Il tag permette di configurare le interfacce di gestione di Wildfly. Posso definire dei security-realm e associarli alle interfacce in modo da definire una modalità di accesso al server. Osservando il file standalone.xml:

                    http-upgrade-enabled="true">
           

possiamo notare che il socket 9990, etichettato come management-http, è associato al security-realm indicato come ManagementRealm. Un security-realm definisce delle condizioni di accesso. Quando associamo un security-realm a una risorsa, l’accesso a questa è subordinato al soddisfacimento delle condizioni poste dal security-realm. Un securiy-realm presenta questa struttura:

Per attivare un security-realm è sufficiente associarlo ad una risorsa, cioè un’interfaccia o una connessione in ingresso, come nel caso del security-realm ApplicationRealm:

        
            security-realm="ApplicationRealm"/>

Nella configurazione di default, l’elemento remoting, che implementa le connessioni in ingresso verso Wildfly, è governato dal security realm ApplicationRealm. Quindi, ad esempio, per invocare un EJB devo presentare delle credenziali che siano congrue con ApplicationRealm.

La configurazione di Wildfly in modalità standalone trova la sua vera peculiarità nella configurazione di un singolo profilo di esecuzione. Questa configurazione è espressa attraverso l’elemento . Il tipo incapsula al suo interno una collezione di elementi .

Di seguito presentiamo alcuni dei subsystem che caratterizzano Wildfly e il suo utilizzo. Non è questa la sede per un trattamento esaustivo di tutti gli aspetti dell’application server. Rimandiamo i lettori alla documentazione offerta da RedHat per approfondire.

logging e datasources subsystem

Questi due elementi permettono, rispettivamente, di configurare gli handler del sistema di logging di Wildfly e di definire risorse per la persistenza dei dati.

Il subsystem ci permette di configurare il servizio di logging per Wildfly. Qui possiamo aggiungere nuovi handler e definire gli elementi . Wildfly permette diversi tipi di handler. Configuriamo un handler d’esempio:

Adesso associamo a questo handler un logger:

In questo esempio, nel file JBOSS_HOME/standalone/log/ejbsec.log verranno riportati tutti i messaggi di log di livello INFO o superiore che provengano da una classe che appartenga al package edu.pezzati.wildfly. Rimandiamo il lettore che voglia esaurire l’argomento al file JBOSS_HOME/docs/schema/jboss-as-logging_2_0.xsd e alla documentazione ufficiale [3].

Wildfly permette di definire un datasource attraverso il subsystem .

Per definire un datasource abbiamo bisogno dei driver per permettere a Wildfly di connettersi al database indicato. Una volta scaricati i driver, questi devono essere resi disponibili come modulo. Per creare un nuovo modulo è necessario aggiungere le librerie alla directory JBOSS_HOME/modules/system/layers/base.

Costruiamo un modulo d’esempio: copiamo i driver appena scaricati, mydatabase.jar, nella directory JBOSS_HOME/modules/system/layers/base/org/mydatabase/main. Aggiungiamo alla directory il file module.xml con le seguenti informazioni:

In questo modo abbiamo un modulo contenente i driver per il nostro database. Possiamo indicare il modulo tramite il valore dell’attributo name. Tale valore deve coincidere con il path del modulo stesso: org/mydatabase.

Non dobbiamo preoccuparci di indicare nel nome la directory main. Se non indicato diversamente, è il suffisso di default del nome di ogni modulo.

Adesso dobbiamo definire l’elemento che rappresenta il nostro database:

        
           ...
                                    pool-name="myDS" enabled="true" 
                         use-java-context="true">
             jdbc:postgresql://localhost:5432/nomedb
             nomecompletoclassedriver
             mydriver
             
                2
                20
                true
             
             
                username
                password
             
             
                SELECT 1
             
           
           …
           
             
           

Il driver è stato dichiarato nell’elemento e indicato nel tag all’interno della definizione di . Un’alternativa è quella di creare un datasource come risorsa da deployare, ovvero copiando i driver nella directory di deployment e usando un file  di tipo …-ds.xml. Quest’ultimo approccio è scoraggiato, in quanto una risorsa di questo tipo non può essere gestita da CLI o AdminInterface. Inoltre, nel caso di un’esecuzione di tipo domain, definire il datasource nell’elemento profile è necessario se si vuole che le istanze di Wildfly possano sfruttare quel database.

deployment-scanner subsystem

Permette di indicare le directory di deploy, di stabilire la frequenza di esecuzione del job di deployment di ciascuna directory e il suo comportamento. Vediamo un esempio:

                               ="jboss.server.base.dir" scan-interval="5000"/>
                               path="C:UsersFrancescojetty-8.1.12webapps" 
                       scan-interval="3000"/>

In questo caso, ho aggiunto come directory di deploy un’altra directory. Diligentemente Wildfly prova a eseguire il deploy delle applicazioni che ho su Jetty…

ee subsystem

Questo tag permette di configurare il comportamento delle applicazioni Java EE ospitate attraverso i seguenti elementi:

• permette di indicare quali moduli saranno visibili alle applicazioni ospitate. Se non viene specificato tramite l’attributo slot, il modulo caricato sarà quello contenuto nella directory main.
• permette di stabilire se i moduli contenuti in ogni pacchetto .ear hanno visibilità l’uno dell’altro.
• , e permettono rispettivamente di cambiare i valori delle system properties indicate nei descrittori ejb-jar.xml e persistence.xml, nei descrittori propri di JBoss, ad esempio jboss-ejb.xml, jboss-web.xml, nelle annotation, con altri valori,  stabiliti nell’elemento system-properties o passati come parametro. La sostituzione viene effettuata al momento del deploy.
• tramite l’elemento Wildfly recepisce la specifica JSR 236, EE Concurrency Utilities. Sull’argomento si rimanda il lettore alla specifica indicata [2] e alla Admin Guide di Wilfly [3].

ejb3 subsystem

In questo subsystem è possibile configurare il comportamento e le prestazioni degli EJB di ogni applicazione ospitata. Da notare che la feature di pooling è disabilitata di default, quindi, ad esempio, per ogni invocazione di un’interfaccia, verrà creata una nuova istanza di uno SLSB. Per abilitare il servizio di pooling per gli SLSB è necessario modificare la  configurazione all’elemento come segue:

        
                                    passivation-disabled-cache-ref="simple"/>
           
           
             
           
        
        ...

L’attributo pool-name fa riferimento al pool censito nell’elemento del subsystem ejb3.

Un altro importante elemento di ejb è . In possiamo definire vari elementi da impiegare nella configurazione degli SFSB. Gli SFSB, per loro natura non possono essere gestiti attraverso un pool di bean anonimi.

L’elemento , indica il thread pool e il datastore che verrà utilizzato da ciascun timer.

Un altro importante elemento di questo subsystem è l’elemento . Tale elemento riveste un ruolo fondamentale nella configurazione del subsystem ejb. Gli elementi , , , e ne sono direttamente influenzati, in quanto l’elemento raccoglie la configurazione che indica quanti thread sono responsabili della gestione delle richieste dei client.

Il subsystem ejb ha una dipendenza nel subsystem remote e nel subsystem io, esplicitata attraverso il suo elemento . L’elemento , tramite l’attributo connector-ref, permette di indicare il tipo di connessione remota attraverso cui esporre le interfacce dei bean. Se guardiamo il file standalone.xml

        ...
                                       thread-pool-name="default"/>
        
            
             
                
           
        
        ...
      
      ...
      
         
                         connector-ref="default" security-realm="ApplicationRealm"/>

notiamo che l’attributo connector-ref indica l’elemento indicato nel subsystem . L’altro attributo di indica la configurazione del pool di thread da impiegare per le richieste dei client.

io subsystem

Come suggerisce il nome, in questo subsystem è definita lla configurazione che permette di determinare il throughtput di Wildfly. Attraverso i suoi elementi e , il subsystem definisce le risorse che l’application server mette a disposizione per gestire le richieste dei client.

security subsystem

Il concetto di è basato su quello di . Wildfly si presenta con due configurati out-of-the-box: ApplicationRealm e ManagementRealm.

ApplicationRealm è impiegato per l’accesso alle applicazioni, ManagementRealm per l’accesso alla CLI e alla Admin consolle. Abbiamo già accennato al ManagementRealm: questo security-realm implementa un controllo all’accesso della CLI verificando che le credenziali fornite  corrispondano all’account di un amministratore indicato nei file mgmt-user.properties e mgmt-groups.properties.

Il subsystem security implementa l’insieme dei security-domain. La definizione del  subsystem è riportata nel file JBOSS_HOME/docs/schema/jboss-as-security_1_2.xsd. Un elemento di tipo è articolato in un insieme di elementi: , , ,
, , .

L’elemento incapsula al suo interno almeno un elemento . Questo elemento ha il compito di definire come verificare le credenziali fornite. Il login ha successo quando sono verificate le condizioni implementate da ogni . Vediamo ad esempio la configurazione definita in standalone.xml. Il subsystem ejb presenta questo elemento:

Il security domain indicato è definito nel subsystem security:

Per accedere a un EJB devo quindi fornire le credenziali necessarie a verificare le condizioni esposte dai due moduli di login. In questo caso, other è il security domain di default del subsystem ejb. Questo security domain presenta un login-module di tipo RealmDirect, e le credenziali di accesso devono soddisfare il realm associato, ossia,  come indicato nel subsystem remoting, ApplicationRealm.

undertow subsystem

Questo subsystem permette di configurare il comportamento del web server Undertow. L’elemento permette di configurare uno o più servizi di cache di contenuti statici. L’elemento rappresenta un’istanza di Undertow:

Un elemento fondamentale di server è . Se diamo un’occhiata alla configurazione qui sopra, osserviamo che ad è associato il socket censito come http. All’elemento è associato anche un . Quando non è indicato in configurazione, come nell’esempio sopra, il associato è il indicato come default nel subsystem io. L’elemento influenza molto il comportamento di Undertow in quanto specifica il numero di thread che questo può utilizzare.

Un altro attributo di è buffer-pool. Anche buffer-pool è definito nel subsystem io e permette di configurare i buffer di IO. Gli altri elementi di sono , , . Gran parte degli attributi di configurazione degli elementi e sono gli stessi impiegati nella configurazione di . L’elemento , invece, permette di definire i virtual host residenti sul server. Rimandiamo il lettore alla documentazione su Undertow [1] e al file JBOSS_HOME/docs/schema/wildfly-undertow_1_0.xsd per avere completa visione degli elementi e dei parametri di configurazione.

Configurazione ed esecuzione del server in modalità domain

Nell’articolo precedente, abbiamo accennato alla modalità di esecuzione domain. In quell’occasione abbiamo visto che questa modalità permette di gestire più istanze di Wildfly in modo centralizzato, raggruppando le varie istanze in gruppi e attribuendo ciascun gruppo a un domain. Un domain è caratterizzato da:

• domain controller
• host controller
• almeno un’istanza di Wildfly

La configurazione di un domain si articola in due file: domain.xml e host.xml. Il file domain.xml raccoglie le configurazioni relative ai profili di esecuzione da attribuire alle istanze di Wildfly che compongono il domain e a come queste istanze sono organizzate in gruppi. Il file host.xml contiene l’elenco delle istanze di Wildfly che compongono il domain e che sono ospitate su quella specifica macchina.

Possiamo eseguire Wildfly con un file di configurazione diverso tramite il comando:

C:UsersFrancescowildfly-8.0.0.Final
          in>domain --host-config=miofilehost.xml

Domain controller

Un’istanza del domain agisce come domain controller, vale a dire che detiene la configurazione dell’intero domain. La macchina designata ad agire come domain controller presenta un file host.xml caratterizzato da questo elemento:

Gli altri host che compongono il domain devono censire le istanze di Wildfly che ospitano nei loro file host-xml:

        
        
        
           
        
                          auto-start="false">
           

Se il domain controller e le istanze che appartengono allo stesso domain non sono ospitate sul medesimo host, le istanze del domain devono sapere come comunicare con il domain-controller:

           <remote
               host="${jboss.domain.master.address}" 
               port="${jboss.domain.master.port:9999}" 
               security-realm="ManagementRealm"/>

In questo esempio ripreso dal file JBOSS_HOME/domain/configuration/host-slave.xml, i valori di host e porta sono parametrizzati, verranno indicati come parametri del comando di avvio del domain. Le condizioni di accesso e autenticazione sono stabilite dal profilo di sicurezza ManagementRealm.

Creare un domain

Adesso proviamo a creare un semplice domain, probabilmente il più semplice domain mai configurato. Creiamo un file di configurazione domain tutto nostro: domain-dummydomain.xml. Questa configurazione di domain è liberamente ispirata a quella contenuta nel file domain.xml…  Ne ometto le parti meno interessanti:

      
        
           ...
        
        
           
           
        
        
           
             ...
           
        
        
           
             ...
           
        
        
        
           
           
           
        
        
           
             ...
           
        
        
           
             
                
             
             
           
        

Abbiamo definito un profilo dummy e un server-group, dummy-server-group. Adesso creiamo il file host-dummydomain.xml: qui dobbiamo definire le istanze di Wildfly che comporranno il nostro domain. Nel file host-dummydomain.xml definiamo la seguente configurazione:

      
      
        
           ...
        
      
        
           
        
      
        
           
             
           
           
              
           
           
             
           
        
      
        
           
             
             
             
               
             
           
        
      
        
           
           
                                                auto-start="true">
             
           
                                                  auto-start="false">
             
           
        

In abbiamo stabilito che tre istanze di Wildfly, server-one, server-two e server-three, saranno ospitate su questa macchina. La stessa macchina è anche domain controller, come indicato in , specificando il tag . Tutte e tre le istanze appartengono al gruppo dummy-server-group, definito nel file di configurazione del domain domain-dummydomain.xml.

Adesso eseguiamo il domain specificando i files di configurazione:

C:UsersFrancescowildfly-8.0.0.Final_ServerGroups
        wildfly-8.0.0.Final in>domain --domain-config=domain-dummydomain.xml 
         --host-config=host-dummydomain.xml

Il nostro domain è in esecuzione. Se proviamo a interrogare Wildfly tramite HTTP, vedremo che agli URL http://localhost:8080/ e http://localhost:8230/ apparirà la welcome page. Interrogando l’URL http://localhost:8330/ riceviamo un errore HTTP 404. Infatti, nel file host-dummydomain.xml, l’istanza in ascolto su quella porta non viene avviata automaticamente, il parametro auto-start è settato a “false“. Possiamo lanciare l’istanza server-three dalla Admin console (figura 1).

Figura 1 – Avvio dell’istanza server-three.

Wildfly Admin console e CLI

Wildfly offre due interfacce di amministrazione: l’interfaccia web, e la CLI. L’accesso a queste due interfacce è definito dal security realm ManagementRealm.

Possiamo raggiungere la console di amministrazione web all’URL http://localhost:9990. Dobbiamo fornire le credenziali di un utente amministratore per poter accedere. La console si presenta con un’interfaccia grafica composta da tre aree ben distinte (figura 2).

Figura 2 – Admin console.

La parte alta della GUI permette di passare da uno all’altro dei tre aspetti di amministrazione di Wildfly: Profile, Runtime, Administration. In modalità domain, questo menu è arricchito dalla voce Hosts.

Profile

L’ambito Profile ci permette di configurare i profili di esecuzione disponibili. Ovviamente, in modalità standalone, il profilo configurabile è uno solo. La parte bassa della GUI mostra a sinistra i subsystem e gli altri elementi di configurazione: interfaces, socket binding e così via. A destra viene mostrato il dettaglio dell’elemento. Qui si possono cambiare i valori e inviarli a Wildfly. Alcuni parametri di configurazione necessitano di un riavvio del server perch��� abbiano effetto; altri, invece vengono recepiti immediatamente. Wildfly restituisce un feedback indicando quando un riavvio è necessario.

Hosts

L’ambito Hosts permette di definire un domain aggiungendo nuove definizioni di gruppi di host e nuove configurazioni con cui eseguire le istanze di Wildfly che compongono il domain. Anche in questo caso, la parte sinistra dell’interfaccia permette di selezionare gli elementi, gruppi oppure host. Nella parte destra, viene mostrato il dettaglio dell’elemento e, se se ne vuole modificare il comportamento, una form per inserire i nuovi parametri di configurazione. Si possono aggiungere nuovi gruppi e host come copia di un elemento preesistente, molto comodo.

Runtime

L’ambito Runtime permette di gestire le istanze di Wildfly che compongono un domain. L’interfaccia permette di avviare o fermare le istanze o i gruppi di istanze, eseguire deploy, gestire le risorse attribuite a ciascun host. Nella parte sinistra dell’interfacia, un menu permette di selezionare l’istanza da osservare. Se Wildfly è eseguito in modalità standalone, allora Runtime permette di gestire la sola istanza corrente, nascondendo il menu a sinistra dove è possibile selezionare il server.

Administration

L’ambito Administration permette la gestione di utenti, dei ruoli e dei gruppi. Qui è possibile creare un nuovo utente e attribuirlo ad un gruppo, od eliminare gli utenti già esistenti.

Interfaccia a linea di comando

Adesso diamo uno sguardo alla CLI di Wildfly. Dalla directory bin, lanciamo la CLI con l’opzione –help:

C:UsersFrancescowildfly-8.0.0.Final in>jboss-cli --help
Usage:
    jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
    [--connect] [--file=file_path] 
    [--commands=command_or_operation1,command_or_operation2...] 
    [--command=command_or_operation] 
    [--user=username --password=password] 
    [--no-local-auth] 
    [--timeout=timeout] 
    --help (-h)     - prints (this) basic description of the command line utility.
    --version       - prints the version info of the JBoss AS release, JVM and system environment.

Qui vediamo che la CLI restituisce uno schema con la sintassi per eseguire i comandi. Ogni comando CLI è strutturato in:

• indirizzo, preceduto dal simbolo  /  (barra inclinata)
• operazione, preceduta dal simbolo  :  (due punti)
• parametri, introdotti mediante parentesi  (  )

La parte di indirizzo di un comando CLI è preceduta dal simbolo  /  e ha la sintassi “tipo di elemento = nome dell’elemento”, per esempio:

/subsystem=datasources/data-source=

CLI ha un sistema di autocompletamento dei comandi molto utile. Ad esempio, utilizzando l’autocompletamento sul comando mostrato, riesco a visualizzare tutti i datasource che ho definito nel file di configurazione dell’istanza di Wildfly a cui sono connesso. Utilizzando l’autocompletamento con il prefisso per l’operazione, CLI mi restituisce tutte le operazioni eseguibili sull’elemento specificato nella parte di indirizzo.

Qualche operazione da CLI

Proviamo adesso ad eseguire qualche operazione. Vi ricordate? Nel precedente articolo avevo creato un datasource denominato testDS. Possiamo navigare tra gli elementi del file standalone.xml e leggere un attributo del nostro datasource:

[standalone@localhost:9990 /] 
       /subsystem=datasources/data-source=testDS:read-attribute(name=jta)
      {
        "outcome" => "success",
        "result" => true
      }
[standalone@localhost:9990 /]

L’attributo jta è valorizzato a true per default. Possiamo cambiarlo semplicemente:

[standalone@localhost:9990 /] 
      /subsystem=datasources/data-source=testDS:write-attribute(
                                         name=jta, value=false)
      {
        "outcome" => "success",
        "response-headers" => {
           "operation-requires-reload" => true,
           "process-state" => "reload-required"
        }
      }
[standalone@localhost:9990 /]

Adesso il nostro standalone.xml è stato modificato. Come ci suggerisce l’output del comando, Wildfly necessita di essere riavviato per applicare la nuova impostazione.

Possiamo spostarci nel documento xml come se fosse un albero di directory:

[standalone@localhost:9990 /] cd subsystem=datasources/data-source=
      [standalone@localhost:9990 data-source] ls
      ExampleDS     demo-ds-pool  testDS
[standalone@localhost:9990 data-source]

Un’altra feature interessante di CLI è la possibilità di usare il comando batch. Con questo comando, è possibile definire una lista di operazioni da eseguire nella sequenza indicata, in modo atomico. Ad esempio, con il comando batch possiamo eseguire il deploy di applicazioni complesse in modo semplice e con un unico comando.

La veste grafica di CLI

CLI possiede anche un’interfaccia grafica. Possiamo avviare CLI nella sua veste grafica tramite il comando

C:UsersFrancescowildfly-8.0.0.Final in>jboss-cli --gui

ed ecco il risultato in figura 3

Figura 3 – CLI interfaccia grafica.

L’interfaccia grafica rende ancora più intuitivo l’uso di CLI. Cliccando con il tasto destro del mouse su un nodo, compare un menu contestuale che indica le operazioni che si possono effettuare. Inoltre, l’interazione con i nodi è rappresentata in comando CLI nella textbox in alto, cmd>. Molto utile ad esempio, per sperimentare istruzioni da inserire in un file di batch per CLI.

Invocazione di un EJB con Wildfly

Sappiamo bene che possiamo invocare un bean tramite la famosa annotation @Inject. Ma per accedere un bean tramite JNDI lookup? Nel precedente articolo di questa serie  abbiamo detto che non esiste più una porta logica dedicata al lookup JNDI ma, grazie alla feature di protocol-multiplexing di Undertow, possiamo eseguire una lookup tramite la porta 8080.

Implementiamo il servizio più semplice del mondo:

import javax.ejb.Remote;
      import javax.ejb.Stateless;
      @Stateless
      @Remote(RemoteHelo.class)
      public class HeloService implements RemoteHelo {
        @Override
        public String greet(String pal) {
           return "Helo "+pal;
        }
      }

eseguiamone il deploy,

17:17:03,694 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6)
      JBAS016002: Processing weld deployment EjbSec-0.0.1-SNAPSHOT.jar
      17:17:03,809 INFO
      [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] 
      (MSC service thread 1-6) JNDI bindings for session bean named HeloService
      in deployment unit deployment 
      "EjbSec-0.0.1-SNAPSHOT.jar" are as follows:
             java:global/EjbSec-0.0.1-SNAPSHOT
                  /HeloService!edu.pezzati.wildfly.security.RemoteHelo
             java:app/EjbSec-0.0.1-SNAPSHOT
                  /HeloService!edu.pezzati.wildfly.security.RemoteHelo
             java:module/HeloService!edu.pezzati.wildfly.security.RemoteHelo
             java:jboss/exported/EjbSec-0.0.1-SNAPSHOT
                  /HeloService!edu.pezzati.wildfly.security.RemoteHelo
             java:global/EjbSec-0.0.1-SNAPSHOT/HeloService
             java:app/EjbSec-0.0.1-SNAPSHOT/HeloService
             java:module/HeloService
      17:17:03,872 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6)
      JBAS016005: Starting Services for CDI deployment: EjbSec-0.0.1-SNAPSHOT.jar

Adesso invochiamo il servizio con il nostro client:

public class HeloTest {
        public static void main(String[] args) {
           Context jndiContext;
           Properties jndiProperties = new Properties();
           
           jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, 
           org.jboss.naming.remote.client.InitialContextFactory.class.getName());
        jndiProperties.put(
                 "jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", 
                                                                                       "false");
           jndiProperties.put(Context.PROVIDER_URL, 
                             "http-remoting://localhost:8080");
           jndiProperties.put(Context.SECURITY_PRINCIPAL, "username");
           jndiProperties.put(Context.SECURITY_CREDENTIALS, "passwd");
           jndiProperties.put("jboss.naming.client.ejb.context", true);
           try {
             jndiContext = new InitialContext(jndiProperties);
             RemoteHelo sr 
                 = (RemoteHelo) jndiContext.lookup(
                    "/EjbSec-0.0.1-SNAPSHOT
                     /HeloService!edu.pezzati.wildfly.security.RemoteHelo");
             System.out.println(sr != null ? sr.greet("Francesco") : "Error.");
           } catch (Throwable e) {
             e.printStackTrace();
           }
        }
}

La novità in questo nostro client consiste nell’istruzione:

jndiProperties.put(Context.PROVIDER_URL, 
      "http-remoting://localhost:8080");

qui entra in gioco Undertow. Se avessimo eseguito il deploy del nostro semplice servizio su JBoss7, avremmo dovuto indicare un protocollo e porta diversi:

jndiProperties.put(Context.PROVIDER_URL, 
      "remote://localhost:4447");

Conclusioni

In questo articolo ci siamo concentrati sugli aspetti di configurazione e di gestione di Wildfly. Abbiamo visto le due modalità di esecuzione dell’application server e abbiamo osservato più da vicino la sua configurazione attraverso il tag profile. Abbiamo visto anche come sia possibile interagire con Wildfly attraverso la sua CLI, uno strumento di gestione potente e versatile.

Riferimenti

[1] Undertow configuration

https://docs.jboss.org/author/display/WFLY8/Undertow+%28web%29+subsystem+configuration

[2] JSR 236

https://jcp.org/en/jsr/detail?id=236

[3] Wildfly Admin Guide

https://issues.jboss.org/browse/WFLY-3639

https://docs.jboss.org/author/display/WFLY8/EE+Subsystem+Configuration