Habilitando o Módulo de Mensageria no JBoss 7

Se você já tentou utilizar recursos de mensageria (API JMS) no JBoss 7, deve ter percebido que este módulo não está habilitado na configuração padrão. Ao executar o servidor em sua configuração standalone e observar o console web de administração não encontraremos nenhuma referência a recursos como filas e tópicos:

 

jboss7_messaging1

 

A primeira vista isto pode ser estranho, pois em versões anteriores do servidor este serviço estava disponível na configuração padrão (default), mas o comportamento é realmente diferente no JBoss 7. Neste pequeno post vamos ver como habilitar este módulo para que seja possível utilizar o JBoss 7, através do serviço HornetQ, como um provedor JMS. Estarei utilizando a versão 7.1.2 do JBoss 7 nos exemplos.

 

Mãos a Obra

Ao executarmos o JBoss 7 em sua configuração standalone, através do arquivo de inicialização jboss-as-7.1.2.Final\bin\standalone.bat (para Windows, ou standalone.sh para linux), a configuração utilizada é a do arquivo jboss-as-7.1.2.Final\standalone\configuration\standalone.xml. Isto pode ser constatado através do arquivo de configurações de inicialização jboss-as-7.1.2.Final\bin\standalone.conf.bat (para Windows, ou jboss-as-7.1.2.Final\bin\standalone.conf para linux), que é utilizado pelo arquivo de inicialização. Nele encontraremos a seguinte linha indicando o arquivo de configurações do servidor utilizado por padrão:

jboss7_messaging2

No arquivo standalone.xml estão as configurações dos serviços (ou módulos) disponibilizados pelo servidor, e nele não encontraremos referências aos serviços de mensageria. Por outro lado, o arquivo standalone-full.xml possui alguns serviços a mais, dentre eles o serviço de mensageria.

Então, para habilitar o serviço de mensageria, temos duas opções: 1) copiar do arquivo standalone-full.xml os trechos de configuração referentes à mensageria e replicar no arquivo standalone.xml; 2) referenciar o arquivo standalone-full.xml no arquivo jboss-as-7.1.2.Final\bin\standalone.conf.bat. Se você possuir restrições quanto aos outros módulos habilitados no arquivo standalone-full.xml, além do serviço de mensagem, escolha a primeira opção.  No entanto se a habilitação de todos os módulos não for um problema escolha a segunda opção. É esta que escolherei. No final, o mesmo trecho de configuração do arquivo jboss-as-7.1.2.Final\bin\standalone.conf.bat estará assim:

jboss7_messaging3

Se agora observarmos o console web de administração encontraremos referências ao serviço de mensageria:

jboss7_messaging4

Incluindo Destinos Personalizados

Se observarmos as configurações de destinos (menu JMS Destinations) não encontraremos nenhum destino (fila ou tópico) previamente configurado:

jboss7_messaging5

Para o modo standalone de execução podemos incluir novos destinos JMS através do arquivo de configurações standalone-full.xml, que estamos utilizando (ou do arquivo standalone.xml, caso você tenha optado pela primeira forma de configuração ).

Inclua o seguinte trecho de código no arquivo de configurações, entre as tags <hornetq-server>…</hornetq-server>:

jboss7_messaging6

No exemplo acima foram incluídos uma fila (queue) e um tópico (topic). Se agora reiniciarmos o servidor e observarmos o console web de administração encontraremos as referências a estes destinos, que poderão ser utilizados para troca de mensagens:

jboss7_messaging7

É isto! Num próximo post vou mostrar como fazer conexões JMS com o servidor a partir de uma aplicação desktop.

Dual Boot: Windows 7 e Ubuntu 12.04 em um Particionamento GPT

Recentemente adquiri um novo notebook cujo disco veio particionado com a arquitetura GPT (GUID Partition Table). Como é de costume, optei por deixar tanto o Windows quanto o Linux instalados (Dual Boot). Esta tarefa costumava ser simples nas máquinas que tive antes, particionadas com MBR, mas tive certa dificuldade para conseguir criar o Dual boot com o GPT.

Apesar de todo o particionamento manual estar aparentemente certo, depois de instalar o Windows, e na sequência o Ubuntu, como geralmente faço, o GRUB não era apresentado no momento do boot para a escolha do SO a ser utilizado, sendo o Ubuntu inicializado automaticamente.

Depois de procurar um pouco encontrei um post que me ajudou a fazer a instalação com Dual Boot com sucesso. Este post me levou a outro, em cujos comentários estão os passos fundamentais para o sucesso.

Antes de comentar estes passos, vale lembrar que eu já havia criado as partições e já tinha realizado a instalação do Windows 7 e do Ubuntu, em suas devidas partições. O único ponto que ainda faltava era fazer o Ubuntu reconhecer a partição do Windows e apresentar as opções no GRUB. Inclusive ao realizar a inicialização pelo Ubuntu, era possível acessar as partições do Windows.

Eis o ponto fundamental a partir daqui (conforme comentário no post citado acima):

The GRUB menu can be unhidden by commenting out the two lines regarding GRUB_HIDDEN in /etc/defaults/grub and running update-grub as root.

Next, the entry for windows can be manually added by appending the following lines to /etc/grub.d/40_custom:
menuentry “Windows” {
    search –fs-uuid –no-floppy –set=root YOUR-EFI-PARTITIONS-UUID-HERE
    chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi
}

Find your EFI partitions UUID by running ‘ls -la /dev/disk/by-uuid/’. As the EFI partition is a FAT32 partition, the UUID is of the form XXXX-XXXX. If you have more than one FAT partition, you can verify if one is the EFI partition by checking the partition map with gdisk (not installed by default). Run gdisk on the device, ‘sudo gdisk /dev/DEVICE’, press ‘p’ to print the partition table, and then ‘q’ to quit. DON’T make any changes to the partition table. The EFI partition will have the code type ‘EF00’ and most likely a name/label that says it is a EFI system partition.

Então, conforme citado no comentário, é necessário comentar o trecho de configuração que oculta o GRUB. Isto pode ser feito comentando as linhas que iniciam com GRUB_HIDDEN no arquivo /etc/defaults/grub:

dual_boot1

Depois disso é necessário incluir uma entrada no arquivo /etc/grub.d/40_custom para a opção de menu do GRUB para o Windows:

dual_boot2

Na imagem acima, o valor BA69-59A5 é o UUID da partição EFI, criada durante o particionamento (ver comentários no primeiro post referenciado). Para se chegar a este valor é necessário executar o comando ls -la /dev/disk/by-uuid/, que dará o UUID da partição EFI no formato XXXX-XXXX (por ser uma partição FAT32):

dual_boot3

Depois de tudo feito execute o comando sudo update-grub e reinicie o sistema. Se tudo der certo o GRUB aparecerá com as opções de boot.

É isso galera, até a próxima!