CERCA SITEMAP FEED RSS 1280
Ultimo aggiornamento: 30 Agosto 2009

Introduzione a JBoss AS 5

JBoss AS 5 è un application server compatibile con Java Enterprise Edition 5 che fornisce un insieme di servizi ai componenti delle applicazioni (Enterprise JavaBeans, Java Serve Pages, Servlet… ).
JBoss AS costituisce il cuore di un middleware noto come JBoss Enterprise Middleware Suite (JEMS) le cui parti si integrano con JBoss AS.

Alcuni di queste sono:
  • JBoss Microcontainer: è il framework di configurazione usato per collegare fra loro i servizi JBoss AS
  • Hibernate: è un framework ORM (Object-Relational Mapping) utilizzato per implementare la persistenza definita dalle specifiche EJB 3.
  • JBoss SX: è un servizio di sicurezza dichiarativo basato su ruoli e utilizzato da altri servizi
  • JBoss Web Server: è il web server che consente l’uso di tecnologie come Servlet, JavaServer Pages, JavaServer Faces…
  • EJB Server: costituisce un’implementazione delle specifiche EJB 3
  • JBoss Messaging: un servizio di messaging compatibile con le specifiche Java Messaging Service (JMS)
  • JBoss Portal: un servizio compativile con le specifiche JSR-168
  • JBoss Cache: una cache transazione e distribuita usata da diversi servizi JBoss AS
  • JBoss Transaction: servizio per la gestione di transazioni

Organizzazione delle directory in JBoss AS 5

Le directory principali di JBoss AS 5 sono:
  • bin: contiene tutti i binary e gli script necessari all’avvio e allo stop di JBoss AS.
  • client: contiene librerie che potrebbero essere utili per comunicare con JBoss AS da un’applicazione client.
    Queste librerie non sono caricate direttamente dal server ma da programmi client che vengono eseguiti su differenti JVM rispetto a quella usata da JBoss AS (tali applicazioni includono standard GUI (Swing o AWT), client di WebServices remoti, web container remoti, client JMS).
    Tipicamente i client remoti invocano EJB, Web Services o JMS in esecuzione sul server.
    Le librerie nella directory client sono usate dai client standaone per fare le chiamate remote a JBoss AS.
    Molte applicazioni (la maggior parte) non faranno uso delle librerie incluse in questa cartella per il semplice fatto che spesso il livello web e business sono collocati sullo stesso server e condividono lo stesso set di librerie.
    I browser possono quindi comunicare con il livello web mediante http e il web tier può comunicare con il livello business e gli EJB mediante chiamate locali.
  • docs: contrariamente a quanto si possa pensare questa directory non contiene manuali utente, guide o javadoc per l’application server bensì file Document Type Definition e XSD per i file di configurazione usati da JBoss AS, esempi di servizi J2EE o JBoss AS, licenze di varie librerie incluse in JBoss AS e risultati di test fatti con particolari release.
    Una directory molto importante è docs/examples/jca che contiene esempi di file di configurazione di datasource per differenti database.
    Per esempio se stiamo usando un database MySQL possiamo copiare il file mysql-ds.xml da questa directory nella directory server/xxx/deploy e modificarne la configurazione.
  • lib: contiene librerie richieste da JBoss AS per avviare il core dell’Application Server.
  • server: in questa cartella sono presenti le cartelle corrispondenti alle possibili configurazioni del server.
Quando viene avviato JBoss AS occorre indicare la configurazione che si vuole caricare: ogni configurazione contiene un insieme di servizi e applicazioni che verranno avviati insieme al server. Ogni configurazione ha a sua volta delle sottodirectory, le più importanti sono conf, lib e deploy.

Configurazione del server

Il cuore di JBoss è un microcontainer al quale è possibile collegare i servizi di cui le applicazioni necessitano.
Oltre alla riduzione dell’occupazione della memoria, il caricamento dei soli servizi strettamente necessari, consente tra le altre cose di avere meno problemi di sicurezza o vulnerabilità.
Sotto ogni directory contentente i file di configurazione del server esistono 4 cartelle principali: conf, deploy, deployers e lib.
In aggiunta a queste, al primo avvio di JBoss AS con una data configurazione, vengono create diverse directory aggiuntive contenenti file temporanei e di log: data, log, tmp e work.
La directory conf che contiene i file usati dalla configurazione del server, viene scannerizzata una sola volta al boot del server pertanto eventuali cambiamenti ai file di configurazione devono essere seguiti da un restart del server affinchè possano avere effetto.

Alcuni dei file di configurazione presenti al suo interno sono:
  • bootstrap.xml: include i riferimenti ad altri file di configurazione che definiscono un serie di POJO o Javabean che forniscono servizi quali:
    • il Profile Service che fornisce informazioni di base sul caricamento dei servizi
    • il kernel JMX
    • bean legati ai deployers (incluso il Main Deployer che gestisce tutti i deployer).
    <?xml version="1.0" encoding="UTF-8"?>
    <bootstrap xmlns="urn:jboss:bootstrap:1.0">
       <url>bootstrap/logging.xml</url>
       <url>bootstrap/vfs.xml</url>
       <url>bootstrap/classloader.xml</url>
       <url>bootstrap/aop.xml</url>
       <url>bootstrap/jmx.xml</url>
       <url>bootstrap/deployers.xml</url>
       <url>bootstrap/profile.xml</url>
    </bootstrap>
    
  • jboss-service.xml: definisce i servizi JMX che vengono avviati insieme al server Jboss-log4j.xml: consente di configurare le opzioni di logging
  • login-config.xml: consente di configurare i moduli di sicurezza per la gestione dell’autenticazione e dell’autorizzazione.
  • standardjboss.xml: consente di configurare i container EJB
La directory deploy è quella nella quale viene effettuato il deploy delle applicazioni e dei servizi (molti servizi usati dalla configurazione del server caricata sono contenuti in questa directory).
In questa cartella viene effettuato il deploy di qualsiasi package sia questo un Java Archive (JAR), un Web Archive (WAR) o un Enterprise Archive (EAR).
Per effettuare il deploy di un’applicazione in JBoss AS è sufficiente copiare l’applicazione nella directory deploy mentre il server è in esecuzione.
La directory deployers contiene tutti i servizi JBoss AS usati per effettuare il deploy dei differenti tipi di archivi: per esempui la directory ejb3.deployer contiene librerie e file di configurazione necessari ad effettuare il servizio di deploy di applicazioni EJB3.
La directory lib contiene le librerie condivise fra tutti i servizi e le applicazioni all’interno della configurazione del server.
La prima volta che viene eseguita una data configurazione di JBoss AS, vengono generate alcune cartelle:
  • data: viene usata dai servizi e dalle applicazioni che necessitano di scrivere nel file system per memorizzare dati temporanei
  • log: contiene tre file di log: boot.log, server.log e audit.log. Il primo è un file temporaneo usato per il logging durante l’avvio di JBoss AS. Il file server.log è il file in cui log4j (il servizio usato da JBoss AS) scrive.
  • tmp: contiene dati temporanei di vari servizi
  • work: è usata dal Web Server JBoss per memorizzare i file JSP compilati e altri dati temporanei.

Microcontainer

Le precedenti versioni di JBoss AS erano costruite attorno a Java Management Extension (JMX) un kernel che forniva un insieme di funzioni base, tutti i servizi erano scritti come ManagedBean (MBeans) e ne veniva fatto il plugin nel kernel JMX.
Con la release 4.0.3, JBoss AS ha iniziato la sua migrazione verso un’architettura microcontainer che consente di scrivere i nuovi servizi come POJO (Plain Old Java Object) piuttosto che come MBeans.

JBoss Microcontainer è un framework che consente di:
  • specificare gli oggetti che devono essere istanziati
  • fornire i parametri al costruttore degli oggetti istanziati
  • specificare le dipendenze tra gli oggetti.
Dal momento che non tutti i servizi sono stati portati all’architettura micrcontainer, il kernel JMX svolge ancora un ruolo di primo piano nell’architettura.
Per configurare il microcontainer è possibile usare i file di configurazione nella cartella server/xxx/conf.
Il file server/xxx/conf/profile.xml definisce alcune delle caratteristiche del microcontainer mediante la dichiarazione di bean:
<deployment xmlns="urn:jboss:bean-deployer:2.0">

  ...

  <bean name="ProfileService" class="org.jboss.system.server.profileservice.basic.MetaDataAwareProfileService">
    <constructor>
      <parameter>...</parameter>
    </constructor>
    <property name="profileRoot">${jboss.server.home.dir}</property>
    ...
  </bean>

  ...

  <bean name="VFSDeployerScanner" class="...">
    <property name="profileService">
      <inject bean="ProfileService"/>
    </property>
    <property name="URIList">
       <list elementClass="java.net.URI">
          <value>${jboss.server.home.url}deployers/</value>
       </list>
    </property>
  </bean>

  ...

</deployment>
Come si vede, ogni bean (tag bean) ha un nome e fa riferimento ad una classe che implementa il bean.
Mediante l’elemento constructor è possibile specificare i parametri da passare al costruttore quando il bean viene creato, mentre attraverso l’elemento property è possibile specificare i valori iniziali per le proprietà dei bean.
Eventuali riferimenti ad altri bean vanno indicati mediante l’elemento inject.

Java Management Extension (JMX)

Le specifiche JMX riguardano i managed bean o MBeans.
Per creare un MBean occorre definire un’interfaccia e una classe che implementa l’interfaccia (l’interfaccia deve avere nome XXXMBean e la classe XXX).
Una volta che l’istanza di un MBean viene creata questa viene registrata mediante un nome nel server Mbean, quindi un client JMX può accedere all’MBean mediante l’MBean server.
Il servizio di deployer istanzia gli MBean in base al contenuto del file jboss-service.xml o vari *-service.xml che appaiono nella cartella di deploy, e li registra presso il server MBean fornito dall’application server.

Il nome di un MBean non è una semplice stringa ma è costituito da più parti:
  • un dominio (simile al nome del package di una classe java)
  • una o più chiavi proprietà (ovvero coppie chiave valore)
Quando è espresso come una stringa il nome inizia col dominio seguito da due punti, seguito dalle proprietà separate da virgola.
jboss.jca:service=ManagedConnectionPool,name=DefaultDS
jboss.system:service=ThreadPool
Il file server/xxx/conf/jboss-service.xml è il file principale isato per dichiarare MBean nel kernel JMX.
E’ possibile usare un differente file descrptor settando la proprietà di sistema jboss.server.root.deployment.filename al nome del file che si vuole utilizzare e settare jboss.server.config.url alla directory che contiene tale file (naturalmente tutti i file di configurazione dovranno poi apparire in questa cartella).

Il file jboss-service.xml definisce un certo numero di bean inclusi:
  • il servizio di logging
  • il thread pool usato per fornire thread per l’esecuzione dei vari servizi
  • Java Naming and Directory Interface
  • MBeans per gestire sicurezza, incluso Java Authentication and Authorization service (JAAS).
  • MBeans collegati ai servizi JMX
  • MBeans collegati ai servizi remoti.
Oltre all’uso di jboss-service.xml è possibile effettuare il deploy di servizi mediante il file Meta-INF/jboss-service.xml nei loro file archivio o mediante un file *-service.xml separato che dichiara l’MBean per il servizio.
Ad esempio nella cartella server/xxx/deploy/messaging è possibile trovare diversi file *-service.xml che definiscono gli Mbeans usati dal servizio di messaging.

Logging

JBoss AS fa uso di log4j, un framework di logging opensource.
Il file di configurazione di log4j è server/xxx/conf/jboss-log4j.xml.
Di default sono definiti due appender: uno per la console le cui entry sono identificate a livello INFO o più alto e uno per il file server/xxx/log/server.log che è settato per loggare tutti i livelli.

Alcuni cambiamenti di configurazione che è possibile apportare a log4j riguardano:
  • i log file da utilizzare
  • i limiti alla quantità di log prodotto
  • l’aggiunta di logging per un’appplicazione
  • la definizione di nuovi file di log
Il file server.log viene creato ogni volta che il server viene eseguito e mantenuto finchè il server non viene spento o si raggiunge la mezzanotte.
Questo comportamento, sebbene sia appropriato in fase di sviluppo non è ottimale per la fase di produzione.
In produzione tipicamente si crea un file di log che crea un nuovo file di log quando raggiunge una carta dimensione.
Il seguente esempio mostra come cambiare l’appender per il file server.log percreare dino a 20 file di log di 10 MB ciascuno:
<log4j:...>
  <appender name="FILE" class="org.jboss.logging.appender.RollingFileAppender">
    <errorHandler .../>
    <param name="File" value="${jboss.server.log.dir}/server.log"/>
    <param name="Append" value="true"/>
    <param name="MaxFileSize" value="10MB"/>
    <param name="MaxBackupIndex" value="20"/>
    <layout .../>
  </appender>

  ...

</log4j>
I vari appender sono sottoclassi degli appender log4j definiti in org.jboss.ogging.appender che creano automaticamente la directory server/xxx/log.
E’ possibile cambiare la locazione del file log mediante la proprietà di sistema jboss.server.log.dir.
Se il file di log cresce troppo rapidamente o si vogliono sopprimere alcuni messaggio presenti sulla console, è possibile cambiare le opzioni di logging per ridurre la quantità di messaggi.
Per fare ciò occorre modificare il file jboss-log4j.xml: ad esempio è possibile eliminare i messaggi con proprità DEBUG di hibernate aggiungendo una priority con value INFO:
<log4j:configuration ...>

  ...

  <category name="org.hibernate">
    <priority value="INFO"/>
  </category>

  ...

</log4j:configuration
E’ possibile aggiungere altre category per rimuovere altri output dal log e ridurre la quantità di logging finale per uno o più servizi.
Per esempio è possibile il logging di JBoss Messaging al livello warning o maggiore mediante la seguetne modifica:
<log4j:...>

  ...

  <category name="org.jboss.messaging">
    <priority value="WARN"/>
  </category>
  <category name="org.jboss.jms">
    <priority value="WARN"/>
  </category>
</log4j>
Infine è possibile limitare quali informazioni di logging inserire in un file di log o in una consola cambiando il valore del parametro Threshold per un dato appender.
<log4j:...>

  ...

  <appender name="CONSOLE" ...>
    <param name="Threshold" value="ERROR"/>
  </appender>

  ...

</log4j>
E' possibile effettuare il logging dell’applicazione aggiungendo le entry nel file jboss-log4j.xml.
Per esempio se l’applicazione usa il package org.jba è possibile effettuare il lobgdelle classi in questo package e nei sottopackage mediante:
<log4j:...>

  ...

  <category name="org.jbia">
    <priority value="DEBUG"/>
  </category>
</log4j>
Esistono casi in cui è preferibile specificare un file di log diverso dal file server.log.
Per esempio supponiamo di volere tutti i messaggi info di tutte le classi org.jbia in un file chiamato jbia.log.

Per fare ciò possiamo scrivere:
<log4j:...>

  ...

  <appender name="JBIA" ...>

    ...

    <param name="File" value="${jboss.server.log.dir}/jbia.log"/>

    ...

  </appender>

  ...

  <category name="org.jbia">
    <priority value="DEBUG"/>
    <appender-ref ref="JBIA" />
  </category>
</log4j>

Proprietà di sistema

Alcune proprietà che sono mantenute in file di configurazione XML possono cambiare in base all’ambiente nel quale JBoss AS viene eseguito.
Per questa ragione il server fornisce supporto per la sostituzione delle variabili nei file di configurazione.
Questo significa che un file di configurazione può usare una variabile al posto del valore fornito per una data proprietà.
Quindi quando il file di configurazione è caricato dall’application server, questo sostituisce la variabile col valore che è stato fornito per la variabile.
Un uso comune di questa capacità prevede il riferimento alle varie proprietà di sistema definite nella sezione precedente.

Le varibili hanno la seguente forma
${some.property.name:the_default_value}
some.property.name è il nome della proprietà il cui valore di default è the_default_value.
Le proprietà di sistema possono essere fornite dall’utente mediante l’opzione -D
run.bat –Dsome.property.name=8000
Oppure è possibile settare i valori nei file run.conf e run.bat oppure mediante il System Properties Service.
Questo servizio consente di fornire un insieme di proprietà nel file di configurazione server/xxx/deploy/properties-service.xml o caricare le proprietà di sistema da uno o più file.properties.
<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss:type=Service,name=SystemProperties">
  <attribute name="URLList">
    http://somehost/some-location.properties, ./conf/somelocal.properties
  </attribute>
  <attribute name="Properties">
    first.property=This is the first value
    second.property=This is the second value
  </attribute>
</mbean>
L’attributo URLList punta ai file properties che contengono le proprietà di sistema.
E’ possibile fornire un URL o una directory relativa alla radice del server: se si forniscono più entry occorre separarle con la virgola.
Il blocco attribute con name Properties configura le proprietà direttamente nel file di configurazione del servizio: ogni proprietà è costituita da una coppia nome/valore su una linea separata.

Deployment di un'applicazione

Il deployment di un’applicazione consta di due passi: dapprima si notifica al web server l’applicazione di cui si vuole effettuare il deploy, quindi l’application server effettua i passi necessari affinchè l’applicazione possa essere utilizzata.
JBoss AS usa un’architettura di deployer a plug-in dove deployer separati sono responsabili del deployng di applicazioni di diverso tipo.
Il modo più semplice di effettuare il deploy di un’applicazione consiste nel piazzarla nella directory server/xxx/deploy: se il server è già avviato allora lo scanner di deployment scannerizza la directory periodicamente e se trova un’applicazione nuova o aggiornata ne effettua il deploy, se il server non è avviato il deploy avviene al suo avvio.
In particolare nel caso di aggiornamento di un’applicazione il server prima effettua l’undeploy e quindi il deploy.
Dal momento che in questo caso lo stato dell’applicazione viene perso (così come qualsiasi stato delle sessioni utente) in ambiente di produzione occorre fare attenzione alla presenza di eventuali sessioni utente attive.
Per effettuare l’undeploy di un’applicazione è sufficiente rimuovere l’applicazione dalla directory di deploy: al successivo scan l’assenza dell’applicazione dalla cartella farà si che il server ne effettui la rimozione.
Un meccanismo alternativo per effettuare il deploy delle applicazioni consiste nell’utilizzare le operazioni di deploy e redeploy messe a disposizione dall’MBean jboss.system:service=MainDeployer e accessibili mediante Console JMX.

Alternativamente è possibile usare l’utility twiddle (cartella bin) utilizzando il comando:
twiddle invoke "jboss.system:service=MainDeployer" deploy /some/path/miapplicazione.ear
Per effettuare l’undeploy si può usare il metodo undeploy dello stesso MBean. Tipicamente un’applicazione si presenta sottoforma di package: un package può essere un file archivio o una directory esplosa.
Se assumiamo di avere un’applicazione che consiste di EJB, Java Archive (JAR) e WAR contenenti l’interfaccia web, è possibile impacchettare questi file in un file EAR chiamato ad esempio miaapplicazione.ear e copiarlo nella directory di deploy.
In alternativa è possibile piazzare i file nella directory miaapplicazione.ear e copiare l’intera directory nella directory deploy.
Nel primo caso effettuiamo il deploy di un archivio, nel secondo il deploy di una directory esplosa.
Entrambi i metodi hanno vantaggi e svantaggi: con un singolo archivio non c’è la possibilità che il deployment dell’applicazione avvenga parzialmente a causa della cancellazione di un file, utilizzando una directory esplosa tutti i file di configurazione e i deployment descriptor sono visibili e facilmente editabili.
Quindi se si edita il deployment descriptor, automaticamente viene fatto i redeploy dell’applicazione.

I principali file archivio sono:
  • war (web archive): il cui deployment descriptor principale è WEB-INF/web.xml
  • ear (enterprise archive): il cui deployment descriptor principale è META-INF/applicazion.xml
  • jar (java archive): il cui deployment descriptor principale è META-INF/ejb-jar.xml
  • sar (service archive): il cui deployment descriptor principale è META-INF/ejb-jar.xml
I principali tipi di applicazioni sono due: applicazioni business e servizi.
Un’applicazione business fornisce una funzione di business agli utenti finali mentre i servizi fornscono funzioni di supporto alle applicazioni.
Per distinguere un tipo di applicazione da un altro si usa un suffisso per il file dell’applicazione o per il nome della directory:
  • .deployer, -deployer-beans.xml: sono tipicamente situati nella cartella server/xxx/deployer e definisco un application deployer utilizzato per il deployment di un particolare tipo di applicazione
  • .aop, -aop.xml: definiscono aspetti che applicati a classi consentono di estenderne le funzionalità
  • .sar, -service.xml: definisce un servizio che aggiunge funzionalità all’application server
  • -jboss-beans.xml: definisce Plain Old Java Object (POJO) per il microcontainer
  • .rar: definisce un resource adaptor
  • -ds.xml: definisce un datasource usato per accedere ad un database
  • .har: definisce un Hibernate archive usato per accedere a un database usando hibernate
  • .jar: definisce un insieme di Enterprise JavaBeans
  • .war: definisce un web archive contenente l’interfaccia web per un’applicazione
  • .ear: definisce un enterprise archive che è una collezione di jar, war e librerie
  • .wsr: definisce un archivio specifico di JBoss per i web services.