Desde a primeira versão Wildfly, o servidor sofreu uma grande mudança em sua estrutura interna que passou a contar com um core leve e extensões que são carregadas conforme necessidade ou por escolha do desenvolvedor.
- Infinispan: esse módulo é uma implementação de provider de cache de segundo nível. Segundo a própria documentação do Wildfly: "provê suporte a cache para serviços de alta disponibilidade: alta performance, cache transacional que pode operar com sistemas distribuídos e não distribuídos".
- ConfigAdmin: (ler sobre módulo OSGi) esse módulo aparece nos wildfly 7.X até a versão 8.0.0-Alpha2 e ao que tudo indica era o módulo que implementava a spec de OSGi. Segundo o site da JBoss, o módulo de OSGi foi externalizado e por isso deixou de aparecer no standalone.xml.
- Connector: não encontrei nada sobre esse módulo. Caso alguém saiba e queira comentar sobre...
- deployment-scanner: esse cara é mais uma funcionalidade do sistema do que necessariamente um módulo. Ele funciona apenas quando o servidor está sendo rodado no modo standalone. Sua função é verificar de tempos em tempos se houve alguma alteração dentro da pasta deployments (pasta padrão de deploy do wildfly no modo standalone) e então realizar o deploy das alterações. Esse link tem uns tópicos legais sobre o deploy no modo standalone
- EJB3: essa nem precisa falar nada né ? Mas pensando bem é sempre bom falar das versões da spec do EJB que foram implementadas em cada versão do wildfly. No JBoss 7.X o EJB segue a especificação versão 3.1, enquanto wildfly 8, 9 e 10 seguem a última versão do EJB que é a 3.2 (final release em maio de 2013). Mais novidades sobre a JSR 345 aqui
- JAX-RS: essa também não. Implementação da spec de webservices através de acesso RESTful
- JDR: acrônimo para JBoss Diagnostic Reporter: pode ser rodado através do jdr.bat ou jdr.sh que está na pasta bin do servidor. Coleta vários dados do servidor fazendo inclusive cópia de arquivos de configuração para análise e dos projetos "deployados". Utiliza por padrão a porta 9990 e o melhor é que pode ser utilizado com o servidor rodando ou parado (no entanto coletará mais informações com o servidor rodando).
- JMX: acrônimo para Java Management eXtensions. É utilizado, e muito útil (diga-se de passargi), para monitoramento e configuração de aplicações de forma remota. Com JMX voce pode "controlar" à distancia, mudar valores de configuração da aplicação sem precisar parar o servidor e tudo mais. É muito bom pra acompanlhar a aplicação de produção na pós-implantação
- JPA: esse tambem não precisa falar. No entanto algo interessante de saber sobre a JPA do JBoss é que até o jboss-7.X o padrão é a implementação do JPA 2.0 já que o servidor atende às especificações da plataforma Java EE 6. Já nos wildfly do 8 pra cima, o suporte é à JPA 2.1. Mas nada impede voce de dizer para o JBoss excluir esse módulo na subida da sua aplicação (através do jboss-deployment-structure.xml) e subir sua própria JPA 2.1 como dependencia do projeto.
- JSF: esse também despensa apresentações. No JBoss 7.X o jsf não é apresentado como um módulo de forma separada, ele faz parte do módulo web. Já nas versões do wildfly 8 pra frente, ele já possui o módulo separado chamado JSF. Aqui vale chamar atenção para as versões dessa spec que os jboss implementam. Desde o JBoss Wildfly 7.X a versão é de implementação do JSF é a 2.1.7. Já no wildfly 8, 9 e 10 (server Java EE 7 certified) a versão de implementação é a 2.2. Quando sair um wildfly Java EE 8 certified (provavelmente a versão 11), aí a implementação do JSF será a 2.3. No entanto a versão 8 da plataforma tem tambem a spec do MVC 1.0 que está extremamente interessante. Vale a pena olhar.
- logging: esse módulo é mais uma facilidade para o desenvolvedor que não precisa se preocupar com API's de log. O próprio servidor te fornece essa api. Se o desenvolvedor não quiser mudar as configurações padrões de log do servidor, basta adicionar nenhum arquivo de configuração. Nesse caso, as configurações padrões ficam definidas dentro do seu próprio standalone.xml. Caso queira personalizar a geração de log, basta por um dos arquivos de configuração abaixo (o servidor irá procurar os arquivos nessa ordem):
- logging.properties
- jboss-logging.properties
- log4j.properties
- log4j.xml
- jboss-log4j.xml
- mail: API de emails do Java. Segue abaixo as versões do servidor e as versões da API utilizadas:
- JBoss 7.X utiliza a versão 1.4.4
- Wildfly 8.1.0 utiliza a versão 1.5.1
- Wildfly 9.0.2 utiliza a versão 1.5.3
- Wildfly 10.X utiliza a versão 1.5.5 (última versão da API)
- naming: Esse subsystem de naming, serve para definirmos objetos para lookup JNDI e a partir do wildlfy 8 (naming versão 2) permite habilitar ou desabilitar lookup JNDI remoto. Nesse link da jboss dá pra olhar exemplo das 4 formas de definir lookups:
- Simple
- Object-Factory
- External-Context
- Lookup
- OSGi: mesmo do ConfigAdmin. Ainda estou pesquisando sobre, mas parece que os dois trabalham juntos.
- POJO: Habilita o deploy de aplicações contendo JBoss Microcontainer Services (suportado pelas versões anteriores do servidor
- remoting: é o sub-sistema de comunicação remota do servidor. Através dele o wildlfy faz os look-ups remotos e acesso a EJB's remotos.
- SAR: Habilita o deploy de arquivos .sar que eram suportados em versões mais antigas do servidor. Os arquivos sar são um compactado como um war ou jar que possui MBeans internos. SAR significa Service Archive
- Security:
- Transactions: Implementação do JTA (Java Transaction API) com o JBoss 7.X implementando a versão 1.1 e o wildfly 8, 9 e 10 implementando a versão 1.2
- Webservices: Esse módulo utiliza o Apache CXF para suporte ao JAX-WS (Construção de webservices com SOAP). A última versão do wildfly até o momento (10.1.0.Final) utiliza o Apache CXF 3.1.6.
- Weld: Implementação do CDI
Aí você me pergunta... pra que eu preciso de saber sobre isso ?
É simples. Por 3 motivos que considero bastante importantes:
1) Migração de aplicação: Quando você tem que fazer a migração do servidor do Wildfly 8 para 10 (como já foi meu caso). É extremamente importante você saber quais as versões das Specs da plataforma EE, os servidores implementam. Isso vai dar uma boa ajuda na hora de migrar aplicação.
2) Otimização do servidor: Muitas pessoas sobem o servidor com standalone-full.xml e nunca ao menos se perguntaram qual a diferença entre o standalone.xml e o standalone-full.xml. E pior... caso você utilize o Spring ao invés do Java EE, voce pode criar seu próprio arquivo standalone customizado subindo apenas os módulos que sua aplicação irá utilizar. Dessa forma, o servidor não precisa carregar um monte de coisas que não serão utilizadas (sim, eu sei que vários serviços ficam no modo passivo)
3) Desenvolvimento da aplicação EE: Caso você opte por criar uma aplicação que utilize as especificações da plataforma EE e vá utilizar os jars disponíveis no servidor de aplicação, é necessário que você saiba quais as versões das API's serão utilizadas. A vantagem nesse caso é que seu artefato (war ou ear) ficará com um tamanho extremamente reduzido.
É simples. Por 3 motivos que considero bastante importantes:
1) Migração de aplicação: Quando você tem que fazer a migração do servidor do Wildfly 8 para 10 (como já foi meu caso). É extremamente importante você saber quais as versões das Specs da plataforma EE, os servidores implementam. Isso vai dar uma boa ajuda na hora de migrar aplicação.
2) Otimização do servidor: Muitas pessoas sobem o servidor com standalone-full.xml e nunca ao menos se perguntaram qual a diferença entre o standalone.xml e o standalone-full.xml. E pior... caso você utilize o Spring ao invés do Java EE, voce pode criar seu próprio arquivo standalone customizado subindo apenas os módulos que sua aplicação irá utilizar. Dessa forma, o servidor não precisa carregar um monte de coisas que não serão utilizadas (sim, eu sei que vários serviços ficam no modo passivo)
3) Desenvolvimento da aplicação EE: Caso você opte por criar uma aplicação que utilize as especificações da plataforma EE e vá utilizar os jars disponíveis no servidor de aplicação, é necessário que você saiba quais as versões das API's serão utilizadas. A vantagem nesse caso é que seu artefato (war ou ear) ficará com um tamanho extremamente reduzido.
