Wildfly

Table
of Contents
Prefácio 1.1
Introdução 1.2
O que é o Wildfly? 1.2.1
Instalação 1.2.2
Requisitos 1.2.2.1
Downloads 1.2.2.2
Instalação passo a passo 1.2.2.3
Criando usuário de gerenciamento 1.2.2.4
Instalando como Serviço no Linux 1.2.2.5
Instalando como Serviço no Windows 1.2.2.6
Estrutura - Cada coisa em seu lugar! 1.3
Diretórios 1.3.1
Arquivos de configuração 1.3.2
Modo Standalone x Domain 1.3.3
Profiles e suas diferenças 1.3.4
Classloader Modular 1.4
O que é e como funciona? 1.4.1
Adicionando um módulo customizado 1.4.2
Definindo dependências explícitas de módulos em sua aplicação 1.4.3
Configurando WildFly 10 1.5
System properties 1.5.1
Socket-bindings 1.5.2
Subsystem datasource 1.5.3
Subsystem mail 1.5.4
Subsystem logging 1.5.5
Subsystem segurança 1.5.6
Subsystem serviços Web 1.5.7
Subsystem Transações 1.5.8
Subsystem servidor Web 1.5.9
Subsystem Remoting 1.5.10
2
Subsystem IO 1.5.11
Subsystem Batch 1.5.12
Subsystem Messaging 1.5.13
Alta disponibilidade (HA) 1.6
Subsystem jGroups 1.6.1
Subsystem Infinispan 1.6.2
Wildfly como loadbalancer 1.6.3
Configurando loadbalancer externos 1.6.4
Modo Domain passo a passo 1.7
Primeiros Passos 1.7.1
3
Prefácio
WildFly - Um livro Opensource

Este livro tem como finalidade levar a comunidade um conteúdo rico para o público e/ou
usuários de WildFly do Brasil, porque não há muitos livros em Português e queremos que
cada vez mais usuários brasileiros utilizem o WildFly e conheçam suas funcionalidades bem
como utilizá-las/configurá-las.
O livro é gratuito e toda e qualquer informação aqui encontrada é de autoria dos membros
da comunidade e do JBUG:Brasil, qualquer novo conteúdo será revisado e googlado antes
de ser publicado. Todo e qualquer conteúdo aqui encontrado pode ser compartilhado porém
de forma alguma poderá ser utilizado para fins comerciais, sendo destinado aos usuários do
Brasil, só será disponibilizado em pt-BR.
Os exemplos utilizados neste livro serão publicados no GitHub no link

https://github.com/jbug-brasil. Caso encontre algum erro e/ou problema durante sua
execução será de altíssima importância sua contribuição para que possamos sempre
melhorar o conteúdo oferecido.
Este livro irá abordar desde a instalação e configuração do Servidor de aplicações WildFly.
Se você está procurando informações sobre o WildFly, este livro é o lugar certo.
Contribuições
O livro está em constante edição e sempre que achar que algum conteúdo ainda não
abordado é interessante por favor nos envie sua sugestão.
Qualquer contribuição é bem vinda, clone o projeto, faça suas alterações e nos envie um
pull request para que possamos validar o conteúdo que você escreveu.
Utilize o GitHub para realizar fork deste livro e efetuar suas alterações. Maiores informações
podem ser encontradas no link abaixo.
Comunidade
Estamos no IRC: No freenode, canal #jbug-brasil e jboss.org.
E também no telegram, grupo JBug Brasil, sinta-se a vontade para entrar no grupo através
deste convite.
4
Prefácio
Erros/Sugestões? :-)
Achou algum erro de qualquer espécie ou até mesmo algum conteúdo que você não
concorde? Sinta-se a vontade para corrigir ou enviar sugestões.
5
Introdução
Introdução
Java é o nome dado tanto à linguagem de programação largamente conhecida quanto à
plataforma por trás da linguagem. Sua popularidade se deve ao fato de que a linguagem é
compilada em um código intermediário (conhecida como Bytecode) para execução dentro
da Máquina Virtual Java (ou JVM). Isso proporcionou ao Java uma série de facilidades na
programação que permite ao desenvolvedor se preocupar somente em programar o que
realmente é necessário para a programação, deixando questões como coleta de lixo
(Garbage Collection), performance de execução de código nativo, gerenciamento de
memória e outros para a Máquina Virtual Java. Tal característica hoje é utilizada em outras
linguagens de programação, como .NET e Python, tamanha a importância da Máquina
Virtual nos paradigmas atuais de linguagens de programação.
Isso proporcionou à Máquina Virtual Java não somente executar programas escritas na
linguagem Java como também outras linguagens. Atualmente, é possível executar
programas escritos em Groovy, Scala, Python, Ruby e outros na Máquina Virtual Java por
conta dessas linguagens disponibilizarem compiladores especiais que permitem criar o
Bytecode para executar na JVM.
6
Introdução
A plataforma Java, desde a sua concepção, recebeu algumas divisões com o objetivo de
tornar a evolução da plataforma focado em seus devidos objetivos, dentre eles podemos
citar:
Java Standard Edition (ou Java SE): É o nome dado à plataforma nas sua mais básica
utilização, cobrindo toda a implementação da Linguagem Java, do Bytecode e da JVM.
Java Enterprise Edition (ou Java EE): É o nome dado à plataforma com foco em
aplicações corporativas (objetivo desde livro), cobrindo características como
persistência de dados, distributabilidade, segurança e outros assuntos pertinentes.
Desde a versão 1.6 do Java EE a plataforma se dividiu em dois perfis (profiles): web:
Onde tudo o que será utilizado/disponibilidado por um fornecedor serão características
que permitem o desenvolvimento de uma aplicação Web full: Onde o que será
utilizado/disponibilizado pelo fornecedor serão todo o perfil Web mais características
adicionais que permitem o uso de componentes como EJB e outros
Java Micro Edition (ou Java ME): É o nome dado à plataforma cujo objetivo é o foco em
dispositivos embarcados (Smartphones, Impressoras, Set-top boxes,
Microcontroladores em geral e outros). Essa plataforma em específico é dividida dois
perfis, sendo eles:
Connected Limited Device Configuration (ou CLDC): Um perfil com foco em
dispositivos que possuem conexão limitada ou nenhuma conexão com a Internet
Connected Device Configuration (ou CDC): Um perfil com foco em dispositivos que
possuem conexão com Internet
Java Card: Uma plataforma muito específica com foco no desenvolvimento de
aplicações que utilizam Smart Cards
Java TV: Uma plataforma com foco para TV Digital (O Ginga, plataforma brasileira para
TV Digital, utiliza partes dessa plataforma)
Há outras plataformas criadas para outros fins, mas não iremos extender em descrever
todas. Conforme já mencionado, o objetivo deste livro está no foco ao Java EE, onde o
Wildfly implementa suas características.
Como assim o Wildfly implementa o Java EE?

As plataformas Java SE e Java ME são administradas pela Oracle, já o Java EE foi
incorporado recentemente e será administrada pela Eclipse Foundation. Além da Oracle e
Eclipse Foundation, outras empresas, Java User Groups (ou JUGs) e indivíduos que
definem as próximas tecnologias a serem desenvolvidas para as próximas versões de suas
plataformas, conhecido como Java Community Process (ou JCP). Nela, é possível discutir
com todos os envolvidos na comunidade Java (ela é livre para quem quiser contribuir) quais
serão as novas tecnologias a serem adicionadas nas próximas versões de suas
7
Introdução
plataformas. Todo o processo de adicionar ou até mesmo melhorar um determinado

componente ou tecnologia da Plataforma Java é feita por um processo formal chamado de
Java Specification Request (ou JSR), onde é atribuído a ela um Expert Group que trabalha
para discutir a especificação daquele componente ou tecnologia.
Sendo assim, a JCP define como determinada plataforma deve ser construída, ficando a
cargo das empresas interessadas em ter um software alinhado àquela plataforma
literalmente implementar aquelas especificações. Hoje, empresas como Oracle, Red Hat e
IBM são as principais que trabalham para implementar essas especificações em suas
soluções.
O Wildfly, então, é uma implementação da plataforma Java EE. Isso significa que todas as
especificações determinadas para uma determinada versão do Java EE (a versão mais
recente é a Java EE 1.7) foram implementadas no Wildfly.
Mas afinal de contas o que é Java EE?

Java EE é o conjunto de JSRs que focam no desenvolvimento de aplicações corporativas
cujo foco está nas seguintes características:
Distributabilidade
Persistência
Segurança
Gerenciamento de Transações
Mensageria
Entre outros...
8
Introdução
É importante lembrar que o objetivo da especificação Java EE (sim, Java EE também é uma
especificação, conhecida como Umbrella Specification) é padronizar o uso de determinadas
tecnologias e portanto ela não tem como objetivo criar inovações tecnológicas em torno da
plataforma. Seu objetivo principal é evitar o fenômeno chamado de Vendor Lock-In, que é
um fornecedor "prender" seus clientes a uma característica muito específica e que altera
uma funcionalidade do Java EE. Claro que há outros aspectos que o Java EE não pretende
controlar, como por exemplo Clustering, sendo esse livre para o fornecedor criar sua própria
implementação. A este caso específico foi dada essa liberdade de implementação para
permitir a livre concorrência entre seus fornecedores e atraí-os para a comunidade Java.
Por que Utilizar Um Servidor de Aplicação?

Um servidor de aplicação fornece todo um ambiente para o deploy e manutenção de
aplicações, seguindo as especificações Java EE, além de possuir uma API para acesso a
todos estes recursos. O Wildfly implementa as especificações Java EE 7, também
conhecida como JEE 7, e é compatível com vários profiles que foram definidos no Java EE
7.
Por que Utilizar Wildfly?

Os principais motivos para utilizar o Wildfly são:
1. Unparalleled Speed: O Wildfly possui um startup mais veloz, o processo de boot foi
otimizado desde o Wildfly 8, agora os processos são iniciado paralelamente para
eliminar esperas desnecessárias e aproveitar o poder dos processadores multi-core.
Os serviços não críticos são mantidos em gelo até o primeiro uso.A partir do Wildfly 8
foi inserido um novo web server de alta performance, o undertow que tem a habilidade
de escalar mais de um milhão de conexões. Isso nos dá a capacidade de atender
alguns requisitos de modernas aplicações web, como: Conectividade, Responsividade
e Habilidade de escalar.
2. Exceptionally Lightweight: O Wildfly fez mudanças significaticas no gerenciamento

de memória. Os serviços de runtime foram desenvolvidos para que alocassem o
mínimo de heap. Com o uso de class loading modular o servidor de aplicação evita
classes duplicadas e que seja iniciado mais módulos que o necessário. Com isso o uso
de memória inicial é reduzido, e também evita-se que o garbage collector fique
pausando o sistema. Ainda é possível adicionar
3. Powerful Administration: As configurações do Wildfly são facilmente gerenciadas, de

compreensão simples e desenvolvida com foco no usuário. Existem tres formas de
gerenciar as configurações no servidor de aplicação: Edição de XML, Por linha de
9
Introdução
comando e utilizando o Gerenciar web. Não se preocupe, iremos abordar esses temas
nos próximos capítulos. Ainda é possível executar o Wildfly de dois modos: Standalone
(uma JVM) ou Domain (várias JVMs), isto também será abordado em capítulos futuros.
4. Supports Latest Standards and Technology: O Wildfly foi todo desenvolvido

baseando-se nas especificações Java EE 7. Com isso o servidor de aplicação provém
ao desenvolvedor capacidade de criar aplicações web com mais facilidade e agilidade.
O Wilfdly também possibilita trabalhar com as novas especificações para web moderna,
como Websockets, JSON-P, REST, JAX-RS 2, etc. Tudo isso graças ao Undertow.
5. Modular Java: O Class loading hierarquico é um problema conhecido, causando entre

outros falhas no momento do deploy de aplicação. O Wildfly faz uso correto de
classloading por meio de módulos que fazem a isolação da aplicação escondendo as
classes de implementação do servidor da aplicação, e apenas “linkando” os Jars que
sua aplicação necessita.
6. Easily Testable: Com a melhora de performance do Wildfly, as aplicações são

facilmente testadas utilizando arquilian.
7. Based on the Best of Open Source: RestEasy, Weld, Hibernate, HornetQ e Arquillian
são algumas das tecnologias que estão presentes no Wildfly.
O que virá nos próximos capítulos?

O livro irá trazer uma breve introdução ao Wildfly, sua arquitetura e depois mostraremos
algumas das tarefas administrativas que podem ser feitas para configurar os componentes
do Java EE, bem como fazer o deployment de aplicações Java EE dentro do Wildfly.
Observação: Todos as aplicações de exemplo utilizadas no decorrer do livro estão

disponíveis no GitHub.
10
O que é o Wildfly?
O que é o Wildfly?
Wildfly, também conhecido como JBoss, é um servidor de aplicação Java EE desenvolvido
em Java e pode ser executado em qualquer Sistema Operacional, 32 ou 64 bits que tenha
suporte ao Java.
Mas se era JBoss, porque o nome foi alterado

para Wildfly após tanto tempo?
Essa é uma ótima pergunta. O principal motivo da alteração ocorreu pelo fato da
semelhança entre o JBoss Application Server(AS) e o JBoss Enterprise Application
Platform(EAP) e também outros produtos do portifólio JBoss gerar um pouco de confusão
entre eles.
Houve então uma votação na comunidade JBoss para decidir o novo nome do projeto da
comunidade. Muitos nomes foram sugeridos (mais de 1500 nomes, de acordo com Mark
Little, CTO da divisão de Middleware da Red Hat) e depois de uma pré-seleção cinco
nomes foram selecionados para a votação da comunidade. Wildfly foi o nome mais votado
entre vários outros, a troca de nomes foi oficialmente anunciada no JUDCon Brazil de 2013
em São Paulo e mais tarde Mark Little postou em seu blog o anúncio.
11
Instalação
Instalação
Este capítulo irá abordar o processo de instalação passo a passo desde os downloads até a
primeira inicialização do Wildfly e também os primeiros passos após sua instalação.
12
Requisitos
Requisitos
Para executar o Wildfly o único requisito é possuir uma máquina física ou virtual
independentemente do sistema operacional com memória suficiente para a execução. A
quantidade de memória necessária pode variar de acordo com a aplicação que será
executada. A configuração padrão do Wildfly está configurada da seguinte maneira:
-Xms64m -Xmx512m
O que significa que o mínimo de memória utilizada é 64mb e pode crescer até 512mb.
Porém o principal requisito é o seu interesse por este magnífico Servidor de Aplicação.
Vamos começar, no próximo tópico vamos aos Downloads e consequentemente a
instalação.
13
Downloads
Downloads
No presente momento, iremos utilizar o Wildfly versão 10.1.0.Final no decorrer dos
próximos tópicos. Sendo este conteúdo atualizado conforme novas versões forem lançadas.
Além das versões Final existem também as Beta e Alpha que são lançadas antes da Final
com o intuito de testar o Servidor de Aplicação para que a versão Final seja o mais perto
possível de ser bug free.
Podemos encontrar todas as versões disponíveis para download neste link, realize o
download da versão 10.1.0.Final ou clique aqui para realizar o download.
Não se preocupe, caso esteja utilizando Windows os próximos passos serão muito
semelhantes, os principais pontos diferentes serão nos arquivos selecionados para
download, também está disponível para download o arquivo extensão .zip.
Após realizado o download do Wildlfy vamos a instalação do Java, caso já o possua

instalado pule esta etapa. O WildFly 10 é Java ee 7, isso quer dizer que o WildFly
implementa todas as especificações propostas pelo Java ee 7, mais detalhes neste link.
Se precisa usar Java 7 não se preocupe, o Wildfly também é compatível com a versão 7 do
Java.
Neste caso irei utilizar a versão 8 do Java que pode ser encontrado neste link.
Lembre-se que para realizar o download do Java é necessário escolher o binário de acordo
com o Sistema Operacional que estiver utilizando. Neste caso estaremos utilizando o
seguinte binário: jdk-8u101-linux-x64.rpm. Se preferir você também pode utilizar o
OpenJDK, o que torna a instalação bem mais simples no Linux
Exemplo (Red Hat like):
CentOS 7+ ou Fedora 22+
$ sudo dnf install java -y
Ou
$ sudo yum install java -y
Porém se estiver utilizando um Sistema Debian Like
14
Downloads
sudo apt-get install openjdk-8-jdk
Após a finalização verifique se o Java foi corretamente instalado e configurado, para isso
basta executar o seguinte comando:
$ java -version
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b14)
OpenJDK 64-Bit Server VM (build 25.101-b14, mixed mode)
Se o resultado for semelhante a este você já está pronto para ir para o próximo tópico.
15
Instalação passo a passo

Neste capítulos iremos abordar a instalação do WildFly partindo do princípio que os
downloads descritos no capítulo anterior já foram realizados.
Bom, como todos nós temos o direito de escolha, para ilustrar os exemplos deste tópico e
dos demais irei usar a seguinte configuração:
Sistema Operacional: Fedora 25 x86_64, Server Edition

Banco de dados: MariaDB 10.0.25-1.fc23
Obs: O banco de dados não será necessário neste primeiro momento, mas será utilizado
em capítulos futuros.
Primeiro passo: Definindo um usuário para Runtime

Segurança em primeiro lugar, evite ao máximo utilizar o usuário root para executar o
WildFly porque desta forma estaremos protegendo o servidor como um todo de forma que
uma aplicação que permita execução de códigos arbritrários não execute nada no servidor
com um usuário privilegiado.
Neste caso utilizarei um usuário chamado _wildfly _que será somente utilizado para
executar o WildFly, para criar o usuário execute o seguinte comando:
# uuseradd -r -g wildfly -d /opt/wildfly -s /sbin/nologin wildfly
Segundo passo: Escolhendo o diretório de instalação

Esta é realmente a primeira dúvida que temos ao realizar a instalação de qualquer
aplicação em nossos servidores, com o WildFly não é diferente. Em poucas palavras, não
existe um padrão definido que todos devem seguir, porém muitos administradores acabam
escolhendo um determinado modelo a seguir para que todos os servidores possuam os
mesmos diretórios/estrutura, isso que, facilita e muito a administração. Eu sempre costumo
usar o diretório /opt, lembrando, isto não é uma regra.
Vamos agora descompactar o WildFly no diretório escolhido:
# tar -xzvf wildfly-10.1.0.Final.tar.gz --directory /opt
Ou se prefere utilizar o arquivo com extensão .zip:
16
unzip wildfly-10.1.0.Final.zip -d /opt
Para facilitar a administração do servidor de aplicação é interessante utilizar link simbólicos

para facilitar uma atualização do WildFly, por exemplo, podemos criar um link simbólico do
diretório wildfly-10.1.0.Final _e chamá-lo somente de _wildfly, e quando sugir uma
atualização de uma nova versão do WildFly basta somente atualizar o link simbólico, assim
scripts de inicialização podem utilizar somente o diretório /opt/wildfly. Para efetuar esta
configuração siga os passos abaixo:
# cd /opt
# ln -s wildfly-10.1.0.Final wildfly
Neste momento já temos o servidor WildFLy descompactado no diretório /opt:
# ll /opt
total 0
drwxr-xr-x. 10 root root 220 Jul 28 01:02 wildfly-10.1.0.Final
Note que as permissões de usuário e grupo estão configuradas para o usuário root, como
boas práticas não iremos utilizar o usuário root para execução do WildFly, e sim o usuário
criado anteriormente, altere as permissões com o seguinte comando:
# chown -R wildfly. /opt/wildfly-10.1.0.Final/
Agora podemos utilizar o usuário wildfly para executar o Servidor.

Abra um shell utilizando este usuário e em seguida acesso o diretório wildfly-10.1.0.Final:
[root@wfly-server ~]$ cd /opt/wildfly-10.1.0.Final/

[root@wfly-server wildfly-10.1.0.Final]$ su -s "/bin/bash" -c "bin/standalone.sh" wild
fly
Com os comandos executados acima estamos:
logando com o usuário wildfly

Acessando o JBOSS_HOME
Iniciando o Wildfly
Caso ocorra tudo bem durante a inicialização do WildFly você terá um log muito semelhante
a este:
[wildfly@wfly-server wildfly-10.1.0.CR1]$ bin/standalone.sh

=========================================================================
17
JBoss Bootstrap Environment
JBOSS_HOME: /opt/wildfly-10.1.0.Final
JAVA: java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m

-Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.
awt.headless=true
=========================================================================
12:32:31,463 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final

12:32:36,598 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
12:32:37,713 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: WildFly Full 1
0.1.0.CR1 (WildFly Core 2.2.0.CR9) starting
12:33:08,472 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creatin
g http management service using socket-binding (management-http)
12:33:09,280 INFO [org.xnio] (MSC service thread 1-4) XNIO version 3.4.0.Beta3
12:33:09,424 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Ver
sion 3.4.0.Beta3
12:33:10,453 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool --
38) WFLYCLINF0001: Activating Infinispan subsystem.
12:33:11,294 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 46) WFLYNAM0001
: Activating Naming Subsystem
12:33:11,259 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 44) WFLYJSF0007: A
ctivated the following JSF Implementations: [main]
12:33:11,960 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 54) WFLYTX0013: No
de identifier property is set to the default value. Please make sure it is unique.
12:33:12,665 INFO [org.jboss.as.naming] (MSC service thread 1-3) WFLYNAM0003: Startin
g Naming Service
12:33:12,893 INFO [org.jboss.as.security] (ServerService Thread Pool -- 53) WFLYSEC00
02: Activating Security Subsystem
12:33:12,900 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 56) WFLYWS
0002: Activating WebServices Extension
12:33:12,897 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 37) WFLYIO
001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based
on your 2 available processors
12:33:13,773 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Curre
nt PicketBox version=4.9.6.Final
12:33:13,872 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thre
ad Pool -- 33) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (versi
on 1.3)
12:33:16,526 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting versio
n 4.0.21.Final
12:33:16,550 INFO [org.jboss.as.connector] (MSC service thread 1-2) WFLYJCA0009: Star
ting JCA Subsystem (WildFly/IronJacamar 1.3.4.Final)
12:33:17,059 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001
: Bound mail session [java:jboss/mail/Default]
12:33:17,359 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT000
3: Undertow 1.4.0.CR4 starting
12:33:17,405 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WF
18
LYJCA0018: Started Driver service with driver-name = h2

12:33:19,060 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55)
WFLYUT0014: Creating file handler for path '/opt/wildfly-10.1.0.CR1/welcome-content' w
ith options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'tru
e', safe-symlink-paths: '[]']
2: Started server default-server.
8: Host default-host starting
12:33:22,573 INFO [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0481: Strict po
ol slsb-strict-max-pool is using a max instance size of 32 (per class), which is deriv
ed from thread worker pool sizing.
12:33:22,575 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0482: Strict po
ol mdb-strict-max-pool is using a max instance size of 8 (per class), which is derived
from the number of CPUs on this host.
6: Undertow HTTP listener default listening on 127.0.0.1:8080
12:33:26,356 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thr
ead 1-1) ISPN000128: Infinispan version: Infinispan 'Chakra' 8.2.3.Final
12:33:26,456 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-2)
WFLYDM0111: Keystore /opt/wildfly-10.1.0.CR1/standalone/configuration/application.keys
tore not found, it will be auto generated on first use with a self signed certificate
for host localhost
12:33:26,582 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (
ServerService Thread Pool -- 61) ISPN000152: Passivation configured without an evictio
n policy being selected. Only manually evicted entities will be passivated.
12:33:26,612 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) W
FLYDS0013: Started FileSystemDeploymentService for directory /opt/wildfly-10.1.0.CR1/s
tandalone/deployments
12:33:26,950 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread
1-4) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
6: Undertow HTTPS listener https listening on 127.0.0.1:8443
12:33:29,599 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS02205
2: Starting JBossWS 5.1.5.Final (Apache CXF 3.1.6)
12:33:30,012 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http managemen
t interface listening on http://127.0.0.1:9990/management
12:33:30,013 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console
19
listening on http://127.0.0.1:9990
12:33:30,013 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 1
0.1.0.CR1 (WildFly Core 2.2.0.CR9) started in 4417ms - Started 331 of 577 services (39
3 services are lazy, passive or on-demand)
Acesse o servidor utilizando o endereço http://localhost:8080, a seguinte página deverá ser

exibida:
No próximo tópico abordaremos a criação do usuário de gerenciamento do WildFly.
20
Criando usuário de gerenciamento

Para conseguirmos utilizar a console de gerenciamento do WildFly é necessário criar um
usário de gerenciamento, também existe usuários de aplicação, segue uma pequena
diferença entre eles:
Management: Usuários utilizados para gerenciar o WildFly utilizando os seguintes

métodos:
Console de gerenciamento
JBoss CLI
Ambos estão disponíveis na porta 9990.
Neste tópico iremos abordar somente a criação de usuário de gerenciamento bem como
acessar a console de gerenciamento.
Caso você tente acessar a console de gerenciamento sem ter antes, criado o usuário você
será redirecionado para a página abaixo informando que é necessário executar o script add-
user.sh (add-user.bat para Windows) para adicionar um usuário de gerenciamento
utilizando o realm ManagementRealm:
Acesse http://localhost:9990
21
Para adicionar o usuário siga os passos a seguir:
Execute o script add-user.sh que está localizado no diretório $JBOSS_HOME/bin
$ ./add-user.sh
What type of user do you wish to add?

a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a):
Por padrão o ManagementRealm é selecionado, apenas aperte enter para prosseguir.
O próximo passo será definir o nome do usuário, escolha um username e prossiga:
22
Enter the details of the new user to add.

Using realm 'ManagementRealm' as discovered from the existing property files.
Username : admin
Logo a seguir você será informado que o usuário admin já existe porém está desativado e
irá lhe mostrar as opções disponíveis:
User 'admin' already exists and is disabled, would you like to...
a) Update the existing user password and roles
b) Enable the existing user
c) Type a new username
(a):
Você terá a opção de atualizar usuário existente e seus grupos, ativar o usuário existente ou
digitar um novo username. Neste caso iremos somente atualizar a senha do usuário admin,
por padrão esta opção já está selecionada, apenas tecle enter.
Agora defina a senha:
Password recommendations are listed below. To modify these restrictions edit the add-u
ser.properties configuration file.
- The password should be different from the username
- The password should not be one of the following restricted values {root, admin, adm
inistrator}
- The password should contain at least 8 characters, 1 alphabetic character(s), 1 dig
it(s), 1 non-alphanumeric symbol(s)
Password :
Re-enter Password :
O próximo passo é definir os grupos, no momento não será necessário definir nenhum,
apenas prossiga:
What groups do you want this user to belong to? (Please enter a comma separated list,
or leave blank for none)[ ]:
Updated user 'admin' to file '/opt/wildfly-10.1.0.Final/standalone/configuration/mgmt-
users.properties'
Updated user 'admin' to file '/opt/wildfly-10.1.0.Final/domain/configuration/mgmt-user
s.properties'
Updated user 'admin' with groups to file '/opt/wildfly-10.1.0.Final/standalone/config
uration/mgmt-groups.properties'
Updated user 'admin' with groups to file '/opt/wildfly-10.1.0.Final/domain/configurat
ion/mgmt-groups.properties'
23
O script irá perguntá-lo se se este usuário será utilizado para autenticação entre 2
servidores WildFly (Veremos com mais detalhes este processo na configuração do modo
Domain). Neste caso será um usuário normal, digite no e tecle enter
Is this new user going to be used for one AS process to connect to another AS process?

e.g. for a slave host controller connecting to the master or for a Remoting connection
for server to server EJB calls.
yes/no? no
Neste momento já estamos aptos a acessar a Console de Gerenciamento, tente acessá-la

novamente e utilize as credenciais que criamos, caso esteja tudo certo você será
redirecionado para a página principal:
Dicas
24
Criando usuário somente com um comando:
$WFLY_HOME/bin/add-user.sh -u admin2 -p teste@123 -s -e
Criando usuários com senhas fracas (não permitido

através do script add-user)
Este método não é recomendado, nunca use-o em produção.
echo -n "username:ManagementRealm:password" | openssl md5

(stdin)= 8959126dd54df47f694cd762a51a1a6f
Com o hash em mãos edite o arquivo $WFLY_HOME/standalone/configuration/mgmt-

users.properties e adicione o novo usuário seguido do hash, exemplo:
username=8959126dd54df47f694cd762a51a1a6f
Caso deseje criar um application user altere a Realm para ApplicationRealm.
Alterando a política de senhas

Também é possível alterar a política de senhas utilizada pelo script de criação de usuários.
No diretório $JBOSS_HOME/bin existe um arquivo chamado add-user.properties com o
seguinte conteúdo:
25
#
# Password restriction
#
# Valid values: RELAX, WARN or REJECT

# RELAX : Don't perform any strength checks on the password in both interactive and no
n-interactive mode
# WARN : Display a message about the strength of the password. Ask confirmation if the
password is weak in interactive mode
# REJECT : Display a message about the strength of the password (if the password is we
ak, the user is not created).
# Ask confirmation if the password is weak in interactive mode
password.restriction=WARN
# Password minimum length

password.restriction.minLength=8
# Password must contains at least one alpha

password.restriction.minAlpha=1
# Password must contains at least one digit

password.restriction.minDigit=1
# Password must contains at least one symbol

password.restriction.minSymbol=1
# Password must not match the username. Valid values: TRUE or FALSE.
password.restriction.mustNotMatchUsername=TRUE
# Comma separated list of forbidden passwords (easily guessable)

password.restriction.forbiddenValue=root,admin,administrator
# Password strength. Valid values: VERY_WEAK, WEAK, MODERATE, MEDIUM, STRONG, VERY_STR
ONG or EXCEPTIONAL.
# If not present, it defaults to "MODERATE"
password.restriction.strength=MEDIUM
# Class of password strength checker.

# If not present, utility will revert to default implementation
password.restriction.checker=org.jboss.as.domain.management.security.password.simple.S
implePasswordStrengthChecker
Para alterar a política de senha conforme suas necessidades apenas edite a propriedade
desejada neste arquivo e salve. As configurações realizadas já serão aplicadas na criação
do próximo usuário.
26
Instalando como Serviço no Linux
Instalando O WildFly como serviço em um

Servidor Linux
Executar Servidores de Aplicação como serviço é muito comum nos dias de hoje, pela
praticidade de gerenciamento e também por ser muito simples a restauração do serviço
após o boot do Sistema Operacional.
No decorrer deste capítulo iremos descrever os passos necessários para configurar o

WildFly Server como um serviço utilizando o systemd como gerenciador de serviços.
Nas versões anteriores do Wildfly, até as versão 9, os scripts estavam no diretório

$JBOSS_HOME/bin/init.d, mas n versão 10 os scripts foram movidos para o diretório
$JBOSS_HOME/docs/contrib/scripts, lembrando que os scripts encontrados neste diretório
são contribuições de usuários e estão disponíveis na distribuíção do WildFly para serem
utilizados como exemplo.
O a criação de um serviço com o systemd é muito simples quando comparado ao init.d.

Para conhecer melhor o systemd acesse este link.
Neste capítulo será exemplificado a instalação do serviço utilizando o init.d e o systemd.
Init.d
Executar o WildFly como serviso utilizando o init.d é um tarefa simples, assim como
utilizando o systemd que será abordado a seguir. Todos os scripts utilizando estão
localizados no diretório $JBOSS_HOME/docs/contrib/scripts/init.d/. Dentro deste diretório
podemos ver os seguintes arquivos:
wildfly-init-redhat.sh : Arquivo a ser utilizado para distribuições Red Hat Enterprise

Linux, como RHEL e Centos;
wildfly-init-debian.sh: Arquivo a ser utilizado para distribuições Debian Linux, como o

Debian e Ubuntu por exemplo;
wildfly.conf: Por fim, o arquivo de configuração utilizado pelos dois arquivos init
descritos acima.
O primeiro passo é copiar o o arquivo de script, de arcordo com sua distribuição Linux, para
o diretório /etc/init.d. Como utilizamos o Fedora, iremos executar o seguinte comando:
27
cp /opt/wildfly/docs/contrib/scripts/init.d/wildfly-init-redhat.sh /etc/init.d/wildfly
Agora precisamos copiar o arquivo de configuração wildfly.conf para onde o script espera
que ele esteja, em /etc/default como podemos observar no script copiado anteriormente:
(...)
# Load JBoss AS init.d configuration.

if [ -z "$JBOSS_CONF" ]; then
JBOSS_CONF="/etc/default/${WILDFLY_NAME}.conf"
fi
[ -r "$JBOSS_CONF" ] && . "${JBOSS_CONF}"
(...)
Para copiar o arquivo, execute o seguinte comando:
mkdir -p /etc/default
cp /opt/wildfly/docs/contrib/scripts/init.d/wildfly.conf /etc/default
O próximo passo será editar o arquivo wildfly.conf previamente copiado com as seguintes
informações:
#Location of Java
JAVA_HOME=/usr/java/jdk1.8.0_45
# Location of WildFly
JBOSS_HOME=/opt/wildfly/
# The username who should own the process.

JBOSS_USER=wildfly
# The mode WildFly should start, standalone or domain

JBOSS_MODE=standalone
# Configuration for standalone mode

JBOSS_CONFIG=standalone.xml
Note que é possível executar em modo domain, além de passar outros parâmetros, como:
28
## The amount of time to wait for startup

STARTUP_WAIT=60
## The amount of time to wait for shutdown

SHUTDOWN_WAIT=60
## Location to keep the console log

# JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log"
## Additionals args to include in startup

# JBOSS_OPTS="--admin-only -b 127.0.0.1"
Dando continuidade, o passo seguinte é instalar o wildfly como um serviço utilizando o

comando chkconfig.
chkconfig --add wildfly
Em seguida, configurar o nível de inicialização onde o serviço será iniciado:
chkconfig --level 2345 wildfly on
Por fim vamos iniciar o serviço:
sudo service wildfly start
Caso tudo ocorra bem, a seguinte saída deve ser mostrada no console:
sudo service wildfly start

Starting wildfly (via systemctl): [ OK ]
Para encerar o serviço, basta executar o comando:
sudo service wildfly stop
Systemd
O arquivo de configuração do systemd disponibilizado na instalação do WildFly já está
pronto para uso, sendo necessário realizar somente alguns passos antes de executá-lo
como serviço.
29
Neste ponto, será necessário ter efetuado os passos descritos no tópico Instalação passo a
passo. Com o ambiente pré configurado, siga os passos abaixo:
# mkdir /etc/wildfly
# cp /opt/wildfly/docs/contrib/scripts/systemd/wildfly.conf /etc/wildfly/
# cp /opt/wildfly/docs/contrib/scripts/systemd/wildfly.service /etc/systemd/system/
# cp /opt/wildfly/docs/contrib/scripts/systemd/launch.sh /opt/wildfly/bin/
# chmod +x /opt/wildfly/bin/launch.sh
# chown wildfly. /opt/wildfly/bin/launch.sh
Como os scripts já estão pré configurados, depois de executar todos os passos acima, já
estamos prontos para iniciar o wildfly.
Primeiramente vamos habilitá-lo para ser executado durante o boot do Sustema

Operacional:
# systemctl enable wildfly

# systemctl start wildfly
E para parar o serviço:
# systemctl stop wildfly
Para configurar o serviço do WildFly para usar o modo Domain ao invés do modo
Standalone (padrão), edite o arquivo wildfly.service localizado em /etc/wildfly conforme o
exemplo abaixo:
# The configuration you want to run

WILDFLY_CONFIG=domain.xml
# The mode you want to run

WILDFLY_MODE=domain
Por padrão o endereço de bind vem configurado como 0.0.0.0, não é uma boa prática
deixá-lo com essa configuração, altere o endeço de bind para o endereço de IP do servidor
em que o WildFly será executado. Para alterar o endereço de bind edite o mesmo arquivo
citado acima da seguinte maneira, como exemplo será utilizado o ip 192.168.1.10:
# The address to bind to

WILDFLY_BIND=192.168.1.10
30
31
Instalando como Serviço no Windows
Instalando O WildFly como serviço em um

Servidor Windows
Como descrito anteriormente em Instalando como Serviço no Linux executar Servidores de
Aplicação como serviço é uma atividade muito comum e trás praticidade para o
gerenciamento do servidor de aplicação.
Instalar o WildFly 10 como um serviço Windows está muito mais simples do que nas
versões anteriores. Não é necessário instalar nenhuma biblioteca de terceiro uma vez que o
WildFly prove tudo que você precisa para executar esta atividade.
Como comentado no capítulo anterior os arquivos para executar o WildFly como serviço
estão localizados na pasta JBOSS_HOME/docs/contrib/scripts/service.
Para instalar o serviço em modo standalone basta executar o seguinte comando dentro da
pasta JBOSS_HOME/docs/contrib/scripts/service pela linha de comando.
service install
Agora você pode gerenciar o serviço, realizando start, stop ou restart pelo Windows
Service. Caso a instalação tenha ocorrido corretamente, será possível ver o serviço em
Windows Service para isto acesse:
1. Abra o menu "Iniciar"

2. Digite " services.msc " na caixa de pesquisa na parte inferior do menu Iniciar
3. Pressione "Enter" para abrir o utilitário Serviços
4. Procure o serviço chamado Wildfly Application Server.
Como alternativa é possível fazer os gerenciamentos básicos do serviço utilizando o

JBOSS_HOME/docs/contrib/scripts/service/service.bat. Veja alguns exemplos a seguir:
service start
service restart
service stop
Para executar em modo domain, é necessário passar mais alguns parâmetros para o
comando service.bat como Domain controller (Por padrão é 127.0.0.1 e porta 9990) e
também o nome do host (por padrão é "master").
Veja o exemplo a seguir:
32
Instalando como Serviço no Windows
service install /controller localhost:9990 /host master
33
Estrutura - Cada coisa em seu lugar!
Estrutura - Cada coisa em seu lugar!

Para ter maior domínio sobre o Wildfly e conhecer melhor o servidor afim de oferecer
melhor administração, é necessário entender toda a estrutura de diretórios dentro do
servidor. O objetivo deste capítulo é mostrar toda sua estrutura, mostrando diretórios
importantes a serem analisados, os perfis de execução do servidor (standalone e domain) e
onde encontrar os arquivos de configuração.
34
Diretórios
Diretórios
O WildFly manteve praticamente a mesma estrutura de diretórios do JBoss AS 7, enxuta e
centralizada. Para aqueles que ainda não estão familiarizados com essa nova estrutura, a
próxima seção descreverá em detalhes abaixo.
Como está dividida a estrutura?

Bom, temos a seguinte estrutura de diretórios:
$JBOSS_HOME
├── appclient
├── bin
│ ├── client
├── docs
│ ├── contrib
│ │ └── scripts
│ │ ├── init.d
│ │ ├── service
│ │ └── systemd
│ ├── examples
│ ├── licenses
│ └── schema
├── domain
│ ├── configuration
│ │ └── domain_xml_history
│ │ ├── current
│ │ ├── snapshot
│ ├── data
│ └── tmp
│ └── servers
├── modules
├── standalone
│ ├── configuration
│ │ └── standalone_xml_history
│ │ ├── current
│ │ ├── snapshot
│ ├── data
│ ├── deployments
│ ├── lib
│ ├── log
│ └── tmp
└── welcome-content
Veremos agora a função de cada diretório e o que é armazenado em cada um:
35
Diretórios
appclient - Este diretório é utilizado para armazenar arquivos de deployments,

configuração e também utilizado como área de escrita utilizados pelo application
client container.
bin - Todos os binários do servidor serão encontratos neste diretório, tais como
standalone/domain.sh|bat, script para adição de usuários, etc.
client - Neste subdiretório está armazenados as bibliotecas necessárias para se
conectar ao Wildfly utilizando JBoss CLI, EJB ou JMS.
docs - Aqui você irá encontrar diversos tipos de arquivos como exemplos de
configuração, exemplos se como executar o WildFLy como serviço, licenças e outros
arquivos que lhe ajudarão a aprender mais sobre o WildFly.
contrib - Arquivos utilizados para executar o WildFly como serviço.
scripts - Scripts para configuração do WildFly como serviço.
init.d - Arquivos necessários para executar como serviço no Linux Linux
baseado no gerenciador de serviços init.d.
service - Arquivos necessários para executar como serviço no Windows
systemd - Arquivos necessários para executar como serviço no Linux
baseado no gerenciador de serviços systemd.
examples - Contém exempls arquivos de configuração do modo standaloe pré
configurados.
licenses - Contém todas as licenças sob o qual o código fonte do WildFLy está
protegido.
schema - São os arquivos que definem as configurações/parâmetros aceitos
nos subsystems presentes nos arquivos de configuração do Wildly, note que
sua nomenclatura contém a versão do schema, asim como no arquivo de
configuração contém a versão do schema que será utilizado para a
configuração de determinado subsystem, Exemplo: Dado o seguinte
subsystem:
<subsystem xmlns="urn:jboss:domain:logging:3.0">
Note que ele está utilizando a versão 3.0 do schema logging. Este mesmo
padrão é válido para todos os outros subsystems.
domain - Abriga toda a configuração do modo domain bem como os arquivos dos
servidores gerenciados (veremos melhor sobre isso mais a frente) e arquivos de
deployments, arquivos temporários e arquivos de logs.
configuration - Contém todos os arquivos de configuração do modo domínio.
domain_xml_history - Contém todo o histórico dos arquivos de configuração.
current - Armazena a configuração corrente com sufixos v1, v2, vX.
snapshot - Armazena os snapshots, obtidos através do comando CLI
/host=HOSTNAME:take-snapshot
36
Diretórios
servers - Diretório utilizado para armazenar informações referentes aos servidores

gerenciados controlados pelo domínio em questão. Dentro do diretório com o
respectivo nome do servidor gerenciado existem também seus subdiretórios data,
tmp e log cujo o objetivo é o mesmo do descrito no modo standalone.
data - Diretório utilizado para persistir dados para que seja possível um restart sem
perda de imformação.
tmp - Utilizado e gerado em Runtime, reponsável por armazenar todos os arquivos
temporários gerados durante a execução do servidor.
lib/ext - Local utilizado para instalar bibliotecas utilizadas pelas aplicações através
do mecanismo Extension-List.
modules - O WildFly é baseado em um classloader modular (explicado em detalhes nos
próximos tópicos), todos os módulos necessários para a execução do WildFly estão
armazenados neste diretório, bem como os módulos customizados.
standalone - Contém todos os arquivos necessários para a execuçaõ do WildFly no
modo standalone.
configuration - Contém todo o histórico dos arquivos de configuração.
standalone_xml_history - Contém todo o histórico dos arquivos de
configuração.
current - Armazena a configuração corrente com sufixos v1, v2, vX.
snapshot - Armazena os snapshots, obtidos através do comando CLI
:take-snapshot
data - Diretório utilizado para persistir dados para que seja possível um restart sem
perda de imformação.
deployments - Existente somente no modo standalone é utilizado para realizar
deployments utilizando o método Deployment Scanner.
lib/ext - Local utilizado para instalar bibliotecas utilizadas pelas aplicações através
do mecanismo Extension-List.
log - Contém os logs do servidor em execuçaõ.
tmp - Diretório para escrita de arquivos temporários utilizados pelas aplicações em
execução.
welcome-content - É um diretório de uso interno do servidor que não deve ser
modificado por usuários finais, sua alteração pode influenciar no funcionamento do
WildFly bem como páginas de boas vindas e páginas de erros.
37
Arquivos de configuração
Desde o JBoss AS 7, a configuração é centralizada o que, de certa forma facilita muito o
gerenciamento do seu servidor ou parque de servidores.
A estrutura, quando comparada com o JBoss AS 7 não teve alterações, porém se você
ainda não a conhece irá achar um pouco estranho a forma como está distribuída agora.
QUando comparada com a versões mais antigas do JBoss, temo uma grande diferença,
principalmente porque os arquivos de configuração eram diversos, em diferentes diretórios,
componentes, etc. Se você está migrando do JBoss AS 6 ou versões anteriores, é de
extrema importância que você leia este capítulo para ficar antenado com a estrutura dos
arquivos de configuração do WildFly.
O intuíto deste tópico será somente descrever os principais arquivos de configurações e sua
aplicabilidade, será tratado em tópicos posteriores como configurar o WildFly.
Para facilitar assunto, o livro dividiremos em três partes:
Configurações em geral;
Configurações do modo standalone;
Configurações do modo domínio.
Configurações Gerais
Iremos começar com as confiugurações bem básicas que são as configurações realizadas
dentro do diterório bin. Nele temos os seguintes arquivos de configuração:
add-user.properties - Configuração da política de senha na criação de usuários

appclient.conf - Arquivo que define as configurações do appclient, utilitário para
execução de applicações sem a necessidade de executar o WildFly
domain.conf - Define as configurações utilizadas para iniciar o modo domínio.
jboss-cli-logging.properties - Definições de log do JBoss CLI.
jboss-cli.xml - Define as configurações que serão utilizadas pelo JBoss CLI, através do
script jboss-cli.sh tais como connection timeout e controller.
standalone.conf - Define as configurações utilizadas para iniciar o modo standalone.
Obs: O wildFly 10 já possui suporte ao PowerShell, note que já há vários scripts com o
sufixo ps1 no diretório bin.
38
Configurações modo Standalone

Todos os arquivos de configuração do modo Standalone estão no diretório
$JBOSS_HOME/standalone/configuration, neste diretório iremos encontrar os seguintes
arquivos:
application-roles.properties: Neste arquivo é configurado as permissões (Roles) dos

usuários utilizados em aplicações.
application-users.properties: Armazena usuários utilizados para autenticação realizada
por aplicações.
logging.properties: Arquivo que define as configurações de log do Wildfly, este arquivo
é alterado de acordo com as definições de logging realizadas no subsystem logging.
mgmt-groups.properties: Grupos dos usuários de gerenciamento, note os grupos são
usados quando o RBAC (Role Based Access Control, falaremos sobre isso nos
próximos capítulos) ou Controle de Acesso Baseado em Roles.
mgmt-users.properties: Define usuários e senha utilizados para autenticar usuários de
gerenciamento.
standalone.xml: Todas as definições e configurações do Wildfly são feitas através deste
arquivo.
Configurações modo Domínio

No modo Domain temos os mesmos arquivos de configuração com a exceção do
standalone.xml e adição dos seguintes arquivos:
domain.xml: Define todas as configurações do modo domínio. Emn adição ao

domain.xml temos mais 3 arquivos:
host-master.xml: Este arquivo define as configuração da instância do WildFly que irá
atuar somente como Controlador de Domínio.
host-slave.xml: Um modo domínio distribuído tem seus host masters e slaves, este
arquivo define as configurações do slaves.
host.xml: Se por acaso desejar executar o WildFly no modo domínio em somente um
servidor, é neste arquivo que estará contidos todas as informações referentes ao host.
Note que também é possível utilizá-lo como host master ou slave.
default-server-logging.properties: Arquivo que define as configurações de log padrão
dos servidores gerenciados.
39
Modo Standalone x Domain

O Wildfly tem dois modos de gerenciamento: Standalone e Domain. Cada modo permite
que você gerencie seus servidores de modo diferente utilizando topologias diferentes.
Modo Standalone
O modo Standalone é o modo tradicional das versões anteriores. Basicamente implica em
ter uma instalação diferente (ou um diretório standalone diferente) para cada instância1 de
Wildfly. Ou seja, para cada Wildfly rodando no seu ambiente é necessário alterar seus
próprios arquivo de configuração, suas próprias opções de execução para JVM, etc.
Modo Domain
O modo Domain é o modo que foi introduzido no JBoss AS 7 onde é possível gerenciar um
conjunto de instâncias Wildfly, agrupando-os e assim permitindo compartilhar configurações
comuns entre eles. Além de compartilhar configurações, é possível também através de um
único console de gerenciamento iniciar ou parar instâncias (ou grupos inteiros), verificar seu
status e estatísticas de cada subsystem (falaremos sobre isso mais adiante), etc.
Qual o melhor modo de gerenciamento?

40
Obviamente, ao analisar os dois modos de gerenciamento, vem aquela famosa pergunta: "E
agora? Qual deles é melhor?". Com certeza a resposta sempre partirá do "Depende", mas
para dar uma ajuda em escolher o melhor modo de gerenciamento é necessário ter em
mente as seguintea perguntas:
O número de instâncias é muito pequeno (algo em torno de 10) ou muito grande?

As máquinas físicas que irão rodar as instâncias estão no mesmo Datacenter ou
espalhados geograficamente?
Eu quero ter um gerenciamento das instâncias individual ou centralizada?
Eu quero ter um controle mais rígido sobre o deployment das aplicações no ambiente?
Com base nessas perguntas, você consegue decidir com bastante clareza e segurança qual
o melhor modo a ser utilizado.
IMPORTANTE: os modos de gerenciamento em nenhum momento afetam Alta

Disponibilidade, Performance ou alguma tecnologia Java EE. Eles apenas definem a
melhor forma de gerenciamento das suas instâncias.
1. Utilizamos o termo instância para denominar um servidor Wildfly rodando
isoladamente. ↩
41
Profiles e suas diferenças

No Java EE, conforme descrevemos na Introdução, é dividido em dois perfis: Web e Full.
Esses perfis (ou profiles) definem o quanto do Java EE será utilizado no desenvolvimento
de suas aplicações. O Wildfly, pensando nesses perfis, criou arquivos de configuração para
cada perfil Java EE bem como adicionou os componentes para HA (High Availability, ou
Alta disponibilidade), que são recursos que permitem o acesso às aplicações hospedadas
no servidor mesmo em caso de falhas.
Arquivo de
Perfil Utilização
configuração*
Web standalone.xml Permite o uso do perfil Java EE Web
Full standalone-full.xml Permite o uso do perfil Java EE Full
Web c/ Permite o uso do perfil Java EE Web com
standalone-ha.xml
HA características de HA
Full c/ standalone-full- Permite o uso do perfil Java EE Full com

HA ha.xml características de HA
* Apenas no modo standalone
Rodando o Wildfly utilizando os profiles

Para rodar o Wildfly utilizando o profiles descritos na seção anterior, basta adicionar a
opção -c à linha de comando pasando o arquivo de configuração a ser utilizado. Exemplo:
Se eu quiser utilizar o perfil Full com HA, basta eu rodar o seguinte comando para iniciar o
Wildfly:
$ ./standalone.sh -c standalone-full-ha.xml
E no modo Domain, como seleciono meu

profile?
O modo domain, assim como explicado no tópico anterior ele é gerenciado por um host
master e cada host slave possui o seu host controller. As configurações dos profiles são
definidas no arquivo domain.xml do Domain Controller que são replicadas a todos os
membros do Domínio.
42
Todos os arquivos de configuração do modo Domínio estão no diretório

$JBOSS_HOME/configuration/domain
Os profiles são estruturados da mesma maneira que os profiles do modo standalone, porém
com uma pequena diferença, repare na tabela abaixo:
Nome do
Perfil Utilização
profile
Web default Permite o uso do perfil Java EE Web
Full full Permite o uso do perfil Java EE Full
Web c/ Permite o uso do perfil Java EE Web com
ha
HA características de HA
Full c/ Permite o uso do perfil Java EE Full com características
full-ha
HA de HA
Veja abaixo um exemplo de uma definição de profile encontrada no arquivo domain.xml:
<profiles>
<profile name="default">
...
<profile name="full">
...
</profiles>
A escolha do profile a ser utilizado por grupo de servidores é feita no também no arquivo
domain.xml da seguinte maneira:
<server-groups>
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="full-sockets"/>
</server-group>
<server-group name="other-server-group" profile="full-ha">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="full-ha-sockets"/>
</server-group>
</server-groups>
O treco a acima é encontrado no final do arquivo e note que em cada definição de grupo de
servidores temos o parâmetro profile para cada um deles.
43
Para iniciar o WildFly no modo domínio basta executar o arquivo

$JBOSS_HOME/bin/domain.sh
44
Classloader Modular
ClassLoader Modular
ClassLoaders são parte de qualquer aplicação Java, nela reserva a responsabilidade de
carregar dinamicamente as classes para a Máquina Virtual Java (JVM) para então criar
objetos a partir daquela classe. Geralmente essas classes são carregadas sob demanda,
ou seja, à medida que objetos são instanciados o ClassLoader carrega o bytecode da
classe em memória.
O ClassLoader é dividido em:
1. Bootstrap
2. Extension
3. System
No Bootstrap ClassLoader todas as classes dentro de JRE/lib/rt.jar são carregadas, bem

como qualquer outra classe de qualquer arquivo .jar que esteja dentro deste diretório. Nele,
todas as classes pertencentes ao pacote java.lang são previamente carregadas, bem como
a própria classe java.lang.Classloader. Já no Extension ClassLoader todas as classes
pertencentes aos arquivos .jar localizados em JRE/lib/ext são carregadas e por fim o
System ClassLoader carrega as classes que estejam dentro do ClassPath, seja ela
45
Classloader Modular
especificada dentro da variável de ambiente CLASSPATH ou então através da opção -

classpath ou -cp do comando java. Ao inicializar a JVM, esses três ClassLoaders são
criados e inicializados. Como pode ver na figura acima, a estrutura do ClassLoader é
hierárquica, ou seja, antes de inicializar o System ClassLoader o Boostrap ClassLoader e o
Extension ClassLoader devem ser carregados primeiro. No Wildfly, a estrutura muda um
pouco e ela é baseada em módulos. Veremos na próxima seção como ela funciona.
46
O que é e como funciona?
O que é e como funciona?

O Wildfly introduziu uma nova forma de estruturar o Classloader, permitindo assim que as
dependências entre as aplicações possam ser mais fáceis de gerenciar.
A estrutura do ClassLoader modular do JBoss previne os problemas conhecidos como JAR

Hell, assim permitindo que duas aplicações possam utilizar bibliotecas jar de diferentes
versões.
47
Adicionando um módulo customizado

Para criar um módulo customizado no Wildly, é necessário criar uma estrutura dentro do
diretório JBOSS_HOME/modules com a seguinte estrutura:
Nome do módulo
├── main
│ ├── module.xml
| └── biblioteca.jar
O módulo precisa ter uma estrutura similar aos pacotes em java, ou seja, se você possui um
pacote chamado br.com.empresa.aplicacao então você precisa ter um diretório criado para
cada nome. Nesse exemplo, teria que haver um diretório com dentro do diretório br
contendo um subdiretório empresa/aplicacao. Dentro dessa estrutura há um diretório main,
onde espera-se que seja a última versão daquele módulo (ou a versão padrão, como quer
que queira chamar). Caso você queira criar várias versões do mesmo módulo, basta criar
um subdiretório dentro do diretório do módulo contendo o nome da versão. Por fim, todos os
arquivos .jar pertencentes a esse módulo devem ser copiados dentro do caminho /main (ou
/versao, caso esteja criando uma nova versão do módulo) e o arquivo module.xml. Esse
arquivo serve como um metadado dentro do módulo, especificando os jars pertencentes a
esse módulo bem como suas dependências. Abaixo um exemplo:
com
├── myjars
│ ├── jfreechart
│ │ ├── main
| │ | ├── jfreechart.jar
| │ | ├── common.jar
| │ | └── module.xml
│ │ ├── 1.0.15
| │ | ├── jfreechart.jar
| │ | ├── common.jar
| │ | └── module.xml
Nessa estrutura existem dois módulos: com.myjars.jfreechart:main e

com.myjars.jfreechart:1.0.15. Assim, eu posso ter uma aplicação que utiliza a primeira
versão do módulo e uma outra aplicação utilizando a segunda no mesmo servidor Wildfly.
O arquivo module.xml
48
Para descrever o módulo, é necessário criar um arquivo xml para indicar os jars
pertencentes a este módulo bem como suas dependências.
<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.1" name="com.myjars.jfreechart">
<resources>
<resource-root path="jfreechart.jar"/>
<resource-root path="jcommon.jar"/>
</resources>
</module>
49
Definindo dependências explícitas de módulos em sua aplicação
Definindo dependências explícitas de

módulos em sua aplicação
Uma vez que criamos nosso módulo customizado, devemos agora definir as dependências
para nossa aplicação. Para isso, utilizamos um arquivo de metadado chamado jboss-
deployment-structure.xml. O arquivo deve estar dentro da raiz da aplicação, no META-INF
ou no caso de aplicações WAR dentro do WEB-INF. Abaixo um exemplo:
<?xml version="1.0" encoding="UTF-8"?>

<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="com.myjars.jfreechart" slot="main"/>
<module name="com.myjars.jcommon" />
</dependencies>
</deployment>
</jboss-deployment-structure>
O módulo com.myjars.jfreechart:main foi adicionado como uma dependência para a

aplicação em questão, permitindo então que as classes desse módulo sejam carregadas
dentro do ClassLoader da aplicação, assim como o módulo com.myjars.jcommon. Nesse
caso, não há um atributo slot especificando qual versão do módulo com.myjars.jcommon
será usada, nesse caso o Wildfly
implicitamente busca por uma versão main e portanto caso o seu módulo possua somente a
versão main ela não será necessária, porém quando há mais de uma versão do módulo
convém sempre definir o parâmetro para dizer qual versão será utilizada.
50
Configurando WildFly 10
Nos próximos tópicos, iremos conhecer como configurar cada componente Java EE do
Wildfly e seus componentes de infraestrutura (como logging), mas antes de darmos início é
necessário entendermos como eles foram desenvolvidos no Wildfly.
Diferente de versões anteriores, o Wildfly centralizou a configuração do servidor em um (no

máximo dois em modo Domain) arquivo de configuração e que através dele é possível
configurar qualquer coisa dentro do servidor. Na verdade, se considerarmos o que seria o
Wildfly, ele é simplesmente uma espécie de Kernel do Wildly (conhecido como Wildfly Core)
onde é possível adicionar funcionalidades a ele (permitindo assim a extensibilidade na sua
arquitetura interna). Para suas funcionalidades foi introduzido os conceitos de extension e
subsystem, que são os blocos lógicos para adicionar/remover das funcionalidades do
servidor e sua configuração. Mas o que significa esses dois conceitos? Veremos em
detalhes a seguir.
Extension
O Extension do Wildfly é a forma como o Wildfly Core pode reconhecer novas
funcionalidades e assim agregar ao seu funcionamento principal. Basicamente, a função do
extension é registrar uma funcionalidade para o Wildfly Core carregar em memória e
também gerenciar o ciclo de vida dela. Por exemplo, as extensions listadas no perfil padrão
(standalone.xml) são as seguintes:
org.jboss.as.clustering.infinispan
org.jboss.as.connector
org.jboss.as.deployment-scanner
org.jboss.as.ee
org.jboss.as.ejb3
org.jboss.as.jaxrs
org.jboss.as.jdr
org.jboss.as.jmx
org.jboss.as.jpa
org.jboss.as.jsf
org.jboss.as.logging
org.jboss.as.mail
org.jboss.as.naming
org.jboss.as.pojo
51
org.jboss.as.remoting
org.jboss.as.sar
org.jboss.as.security
org.jboss.as.transactions
org.jboss.as.webservices
org.jboss.as.weld
org.wildfly.extension.batch.jberet
org.wildfly.extension.bean-validation
org.wildfly.extension.io
org.wildfly.extension.request-controller
org.wildfly.extension.security.manager
org.wildfly.extension.undertow
Subsystem
Subsystem nada mais é que a funcionalidade em si implementada e que é registrada no
Wildfly Core pela Extenstion. Nela, é possível extender a funcionalidade através da
configuração via xml. O Subsystem é onde realmente você terá o suporte a Servlets no
Wildfly, EJB, Transações, Logging, etc. Como exemplo, abaixo temos a configuração do
subsystem Logging:
52
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
<periodic-rotating-file-handler name="FILE" autoflush="true">
<formatter>
<named-formatter name="PATTERN"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
<logger category="com.arjuna">
<level name="WARN"/>
</logger>
<logger category="org.jboss.as.config">
<level name="DEBUG"/>
</logger>
<logger category="sun.rmi">
<level name="WARN"/>
</logger>
<root-logger>
<level name="INFO"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="FILE"/>
</handlers>
</root-logger>
<formatter name="PATTERN">
<pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t)
%s%e%n"/>
</formatter>
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %
s%e%n"/>
</formatter>
</subsystem>
Histórico de alterações
Uma das maiores funcionalidades no Wildfly é o registro histórico de configurações. Dessa
forma, se houver qualquer alteração nos arquivos de configuração (seja ela editando
manualmente o arquivo, via JBoss CLI ou Console Web), o Wildfly irá criar um backup das
alterações. Isso permite que no caso de alguma alteração afetar negativamente o ambiente
é possível reverter a alteração apenas copiando a última versão alterada.
53
A estrutura de histório está descrita no capítulo Diretórios. Para recuperar o arquivo, basta
sobreesrcrever o atual com um dos snapshots que ficam dentro do diretório snapshots (o
snapshot é o nome do arquivo de configuração seguido da data e hora de alteração).
2. NIC = Network Interface Card, ou simplesmente Interface de Rede ↩
3. Definimos offset a soma a ser colocada no número da porta de cada Socket Binding
definido no grupo. Ex. Se definir um offset de 150 e a porta definida para o Socket
Binding http é 8080, então o número da porta é 8230. ↩
54
System properties
System properties
Voltando rapidamente ao tópico Interfaces, reparou em algo interessante na configuração?
Vou copiar o trecho aqui para deixar mais claro:
...
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
...
Perceba que o valor atribuido aqui foi escrito no formato de uma EL4, ou seja, é possível
definir dinâmicamente um valor a ele ou apenas aceitar o valor padrão (que no caso desse
exemplo é 127.0.0.1 ). Essa funcionalidade permite que você utilize placeholders dentro
dos arquivos de configuração permitindo que você defina esses valores ao inicializar o
servidor sem precisar configurar os arquivos para cada instância.
Para inicializar uma instância de Wildfly alterando esse valor, basta que você execute o
Wildfly dessa forma:
$ bin/standalone.sh -Djboss.bind.address=192.168.1.100
Esse comando irá iniciar uma instância de Wildfly com todos os seus serviços respondendo
ao IP 192.168.1.100 . A opção -D da linha de comando é parte do java e é conhecido
como System Property, onde qualquer aplicação Java pode receber valores dinâmicamente
ao iniciar a JVM. O Wildfly fez uso dessa funcionalidade para tornar a configuração dos
seus subsystems mais fáceis de alterar de instância para instância.
Configurando System Properties usando

JBoss Web Console
É Possível configurar também as System Properties via Web Console. Dessa forma, é
possível configurar sem precisar alterar os parâmetros de inicialização. No entanto, ainda
assim é necessário reiniciar o servidor.
Para Adicionar uma System Property através da console de gerenciamento, siga os passos
abaixo:
55
System properties
Clique na aba Configuration
Clique em System Properties
56
System properties
Clique em View
Clique em Add . Preencha com o nome da System Property e seu valor e depois clique
em Save
57
System properties
Configurando System Properties usando

JBoss CLI
Tbém é possível utilizar o JBoss CLI para configurar as System Properties. Para isso, basta
executar o script jboss-cli.sh e execute o seguinte comando:
/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
Exemplo:
/system-property=jboss.bind.address:add(value=192.168.1.2)
Configurando System Properties como

parâmetro da JVM
Também é possível configurar uma System Property através da linha de comando quando
for iniciar o WilFly, é bem simples, porém não é persistente, se o WildFly for reiniciado e a
propriedade não for configurada novamente, não terá efeito, para estes casos é
recomendado utilizar um dos métodos citados acima. Uma System Property é configurada
da seguinte maneira:
58
System properties
-Dminha.propriedade=meu_valor
Repare no -D, é este prefixo que define que o valor que o sucede é uma SystemProperty e
o que está depois do sinal de igual = é o seu respectivo valor.
Desta maneira, para configurarmos uma System Property na inicialização do WildFly,

podemos fazer da seguinte maneira:
$WFLY_HOME/bin/standalone.sh -Dminha.propriedade=meu_valor
Utilizando System Properties no modo Domain

System Properties são muito úteis em ambientes utilizando o modo Domain, pois é possível
configurar o escopo das System Properties das seguintes formas:
Geral (Aplica a todos os servidores daquele ambiente):
[domain@localhost:9990 /] /system-property=minha.propriedade:add(value=test)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => {
"main-server-group" => {"host" => {"master" => {
"server-one" => {"response" => {"outcome" => "success"}},
"server-two" => {"response" => {"outcome" => "success"}}
}}},
"other-server-group" => {"host" => {"master" => {"server-three" => {"respons
e" => {"outcome" => "success"}}}}}
}
}
E se verificarmos em um dos servidores gerenciados, como por exemplo o server-one _que

pertence ao grupo de servidores _main-server-group a propriedade de sistema estará
presente neste servidor, e também no server-three:
59
System properties
[domain@localhost:9990 /] /host=master/server=server-one/system-property=minha.prope
rty:read-resource
{
"result" => {"value" => "test"}
}
[domain@localhost:9990 /] /host=master/server=server-three/system-property=minha.pro
perty:read-resource
{
}
Server Group (Aplica aos servidores daquele Server Group específico), neste caso
outra propriedade de sistema será adicionada para validar a configuração:
[domain@localhost:9990 /] /server-group=other-server-group/system-property=other.ser
ver.group:add(value="Outra Grupo de Servidores")
{
"result" => undefined,
"server-groups" => {"other-server-group" => {"host" => {"master" => {"server-thr
ee" => {"response" => {"outcome" => "success"}}}}}}
}
Note que esta propriedade de sistema estará disponíveis somente para servidores
gerenciados membros do grupo de servidores other-server-group. Note que ela não está
disponível no server-one:
[domain@localhost:9990 /] /host=master/server=server-one/system-property=minha.prope
rty:read-resource
{
}
Server (Aplica-se em uma única instância ou servidor gerenciado), será adicionada

uma nova propriedade de sistema no servidor server-one: VERIFICAR DEPOIS,
/host=master/server=server-one/system-property=test:
No caso de haver uma System Property em mais de um escopo, prevalece aquele que é
mais específico. Ou seja, havendo a mesma System Property Geral e no Server Group,
prevalece a do Server Group, da mesma forma que se houver a mesma System Property no
Server Group e no Server, prevalece a do Server.
60
System properties
Manipulando System Properties em uma

Aplicação Java
4. Expression Language ↩
61
Socket-bindings
Socket-bindings
Socket Bindings define o conjunto de Sockets a serem utilizados pelos Subsystems do
Wildfly. Nele, você pode definir um nome lógico para esse socket, a porta a ser utilizada, a
qual Interface irá responder, se o tráfego é somente de saída, etc. Além disso, com a tag
3
<socket-binding-group> , é possível definir um offset de portas para que instâncias
diferentes rodando na mesma máquina física não tenham conflito de portas. Abaixo temos
uma configuração de Socket Binding para o perfil Web:
<socket-binding-group name="standard-sockets" default-interface="public" port-offs

et="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.ma
nagement.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.m
anagement.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
Como configurar
Além da configuração manual no XML, é possível também alterar os Socket-Bindings de
outras maneiras a seguir:
Via Web Console

Clique em Configuration
62
Socket-bindings
Clique em Socket Binding
Clique em View
63
Socket-bindings
Aparecerá a listagem dos Socket Bindings disponíveis, onde é possível

Adicionar/Remover/Editar os Socket Bindings
Via CLI
/socket-binding-group=new-sockets:add(default-interface=public)
/socket-binding-group=new-sockets/socket-binding=new-socket-binding:write-attribute(na
me=interface,value=unsecure)
64
Socket-bindings
Definindo Port Offset em modo Domain

/host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset
,value=250)
Interfaces
Interfaces são denominações lógicas para interfaces de rede que irão se associar aos
sockets (ver próxima seção) para expor algum serviço de rede para os Subsystems. As
Interfaces podem associar os sockets para um IP em específico ou até mesmo para uma
NIC2 da máquina física, permitindo então dedicar o tráfego de rede dos Subsystems do
Wildfly passar por uma interface específica de rede. Abaixo temos um exemplo de
Interfaces:
<interfaces>
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
<interface name="internal">
<nic name="eth1"/>
</interface>
</interfaces>
65
Subsystem datasource
Subsystem datasources
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
<driver>h2</driver>
<pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="Examp
leXADS">
<driver>h2</driver>
<xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
<xa-pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</xa-pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</xa-datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
Utilizando driver JDBC como deployment

Baixe o Driver JDBC
66
Se o Driver JDBC do fornecedor ainda não é compatível com a versão JDBC 4, veja na
seção Tornando o Driver JDBC compatível com a versão 4 para converter o Driver.
Faça o deploy do Driver JDBC:
$ EAP_HOME/bin/jboss-cli.sh
$ deploy driver-jdbc.jar
Caso o deploy tenha sido feito com sucesso, você verá a seguinte mensagem no log do
servidor:
WFLYJCA0018: Started Driver service with driver-name = jdbc-driver.jar_com.sua.classe.

jdbc
Instalando driver JDBC como módulo

Baixe o Driver JDBC
Se o Driver JDBC do fornecedor ainda não é compatível com a versão JDBC 4, veja na
seção Tornando o Driver JDBC compatível com a versão 4 para converter o Driver.
Execute o JBoss CLI
$ EAP_HOME/bin/jboss-cli.sh
No prompt do JBoss CLI, execute o seguinte comando:
module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES
Um exemplo para adicionar o Driver JDBC seria assim:
module add --name=com.mysql --resources=/caminho/do/mysql-connector-java-5.1.36-bin.ja

r --dependencies=javax.api,javax.transaction.api
Ao executar o comando anterior, o Wildfly irá:
Criar um subdiretório WILDFLY_HOME/modules/com/seu/modulo/jdbc/main

Copiar o JAR dentro desse diretório
Criar um arquivo module.xml contendo a configuração para o módulo (Veja a
seção Adicionando um módulo customizado para maiores detalhes)
Conecte-se à instância do Wildfly com o seguinte comando:
67
connect
Registre o Driver JDBC, passando o nome do módulo recém-adicionado:
/subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-modu
le-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-c
lass-name=DRIVER_CLASS_NAME)
Um exemplo para adicionar o Driver JDBC do MySQL seria:
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.
mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource,
driver-class-name=com.mysql.jdbc.Driver)
Tornando o Driver JDBC compatível com a

versão 4
Crie um diretório temporário para hospedar os arquivos.
Crie dentro desse diretório um subdiretório META-INF/services
Dentro do subdiretório META-INF/services, crie um arquivo chamado java.sql.Driver
Abra o arquivo e escreva em uma única linha o nome completo da classe com o seu
pacote(denominado Fully-Qualified Class Name). Exemplo para o Driver do MySQL;
com.mysql.jdbc.Driver
Utilize o comando jar do Java para incluir o novo arquivo no Driver JDBC:
$ jar \-uf driver-jdbc.jar META-INF/services/java.sql.Driver
68
Subsystem mail
Subsystem Mail
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-s
mtp:add(host=localhost, port=25)
/subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
/subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-
smtp, username=user, password=pass, tls=true)
@Resource(lookup="java:jboss/mail/MySession")
private Session session;
Configurando um servidor POP3

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-p
op3-binding:add(host=localhost, port=110)
/subsystem=mail/mail-session=mySession/server=pop3:add(outbound-socket-binding-ref=my-
pop3-binding, username=user, password=pass)
Configurando um servidor IMAP

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-i
map-binding:add(host=localhost, port=143)
/subsystem=mail/mail-session=mySession/server=imap:add(outbound-socket-binding-ref=my-
imap-binding, username=user, password=pass)
Enviando seu primeiro email com uma

aplicação java
69
Subsystem logging
Subsystem Logging
Em modo Standalone: WILDLFY_HOME/standalone/server/log
Em modo Domain: WILDFLY_HOME/domain/servers/SERVIDOR/log/server.log
Configurando Logging
Em modo Standalone: WILDFLY_HOME/standalone/configuration/logging.properties
Em modo Domain: WILDFLY_HOME/domain/servers/SERVIDOR/data/server.log
Inspecionando erros em tempo de bootstrap

/core-service=management:read-boot-errors
Configurando Logging por aplicação

<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.3.0.Final-redhat-1</version>
<scope>provided</scope>
</dependency>
import org.jboss.logging.Logger;
private static final Logger LOGGER = Logger.getLogger(MinhaClasse.class);
LOGGER.debug("debug");
LOGGER.info("info");
LOGGER.error("error");
LOGGER.trace("trace");
LOGGER.fatal("fatal");
Para empacotamentos EAR, no diretório META-INF

Para empacotamentos WAR, no diretório WEB-INF/classes
70
Subsystem logging
Desabilitando Logging por aplicação
/subsystem=logging:write-attribute(name=use-deployment-logging-config,value=false)
Visualizando arquivos de log
71
Subsystem segurança
72
Subsystem serviços Web
73
Subsystem Transações
74
Subsystem servidor Web
75
Subsystem Remoting
76
Subsystem IO
77
Subsystem Batch
Subsystem batch
<subsystem xmlns="urn:jboss:domain:batch-jberet:1.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
78
Subsystem Messaging
Subsystem Messaging
79
Alta disponibilidade (HA)
80
Subsystem jGroups
81
Subsystem Infinispan
82
Wildfly como loadbalancer
83
Configurando loadbalancer externos
84
Modo Domain passo a passo
85
Primeiros Passos
86

Wildfly

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Wildfly

Enviado por

Direitos autorais:

Formatos disponíveis

Table

WildFly - Um livro Opensource

Os exemplos utilizados neste livro serão publicados no GitHub no link

Como assim o Wildfly implementa o Java EE?

plataformas. Todo o processo de adicionar ou até mesmo melhorar um determinado

Mas afinal de contas o que é Java EE?

Por que Utilizar Um Servidor de Aplicação?

Por que Utilizar Wildfly?

2. Exceptionally Lightweight: O Wildfly fez mudanças significaticas no gerenciamento

3. Powerful Administration: As configurações do Wildfly são facilmente gerenciadas, de

4. Supports Latest Standards and Technology: O Wildfly foi todo desenvolvido

5. Modular Java: O Class loading hierarquico é um problema conhecido, causando entre

6. Easily Testable: Com a melhora de performance do Wildfly, as aplicações são

O que virá nos próximos capítulos?

Observação: Todos as aplicações de exemplo utilizadas no decorrer do livro estão

Mas se era JBoss, porque o nome foi alterado

Após realizado o download do Wildlfy vamos a instalação do Java, caso já o possua

Exemplo (Red Hat like):

CentOS 7+ ou Fedora 22+

$ sudo dnf install java -y

$ sudo yum install java -y

Porém se estiver utilizando um Sistema Debian Like

sudo apt-get install openjdk-8-jdk

Instalação passo a passo

Sistema Operacional: Fedora 25 x86_64, Server Edition

Primeiro passo: Definindo um usuário para Runtime

# uuseradd -r -g wildfly -d /opt/wildfly -s /sbin/nologin wildfly

Segundo passo: Escolhendo o diretório de instalação

Vamos agora descompactar o WildFly no diretório escolhido:

# tar -xzvf wildfly-10.1.0.Final.tar.gz --directory /opt

Ou se prefere utilizar o arquivo com extensão .zip:

unzip wildfly-10.1.0.Final.zip -d /opt

Para facilitar a administração do servidor de aplicação é interessante utilizar link simbólicos

Neste momento já temos o servidor WildFLy descompactado no diretório /opt:

# chown -R wildfly. /opt/wildfly-10.1.0.Final/

Agora podemos utilizar o usuário wildfly para executar o Servidor.

[root@wfly-server ~]$ cd /opt/wildfly-10.1.0.Final/

Com os comandos executados acima estamos:

logando com o usuário wildfly

[wildfly@wfly-server wildfly-10.1.0.CR1]$ bin/standalone.sh

JBoss Bootstrap Environment

JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m

12:32:31,463 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final

LYJCA0018: Started Driver service with driver-name = h2

Acesse o servidor utilizando o endereço http://localhost:8080, a seguinte página deverá ser

No próximo tópico abordaremos a criação do usuário de gerenciamento do WildFly.

Criando usuário de gerenciamento

Management: Usuários utilizados para gerenciar o WildFly utilizando os seguintes

Ambos estão disponíveis na porta 9990.

Para adicionar o usuário siga os passos a seguir:

Execute o script add-user.sh que está localizado no diretório $JBOSS_HOME/bin

What type of user do you wish to add?

Por padrão o ManagementRealm é selecionado, apenas aperte enter para prosseguir.

O próximo passo será definir o nome do usuário, escolha um username e prossiga:

Enter the details of the new user to add.

Agora defina a senha:

Neste momento já estamos aptos a acessar a Console de Gerenciamento, tente acessá-la

Criando usuário somente com um comando:

$WFLY_HOME/bin/add-user.sh -u admin2 -p teste@123 -s -e

Criando usuários com senhas fracas (não permitido

echo -n "username:ManagementRealm:password" | openssl md5

Com o hash em mãos edite o arquivo $WFLY_HOME/standalone/configuration/mgmt-

Caso deseje criar um application user altere a Realm para ApplicationRealm.

Alterando a política de senhas

wildfly-init-redhat.sh : Arquivo a ser utilizado para distribuições Red Hat Enterprise

wildfly-init-debian.sh: Arquivo a ser utilizado para distribuições Debian Linux, como o