Weblogic WLST - Erro ao inicializar servidores via nodemanager.

Um erro recorrente e chato que acontece comumente quando utilizamos um script para controlar o ciclo de vida(para, pausar, reiniciar) dos servidores gerenciados no domínio do weblogic utilizando conexão via nodemanager é um erro de acesso com a mensagem similar a esta:

Connecting to Node Manager ... This Exception occurred at Wed Jan 27 11:31:34 BRST 2010. weblogic.nodemanager.NMException: Access to domain 'testescripts' for user 'weblogic' denied at weblogic.nodemanager.client.NMServerClient.checkResponse(NMServerClient.java:298) at weblogic.nodemanager.client.NMServerClient.checkResponse(NMServerClient.java:311) at weblogic.nodemanager.client.NMServerClient.connect(NMServerClient.java:253) at weblogic.nodemanager.client.NMServerClient.checkConnected(NMServerClient.java:196) at weblogic.nodemanager.client.NMServerClient.checkConnected(NMServerClient.java:202) ...... WLSTException: Error occured while performing nmConnect : Cannot connect to Node Manager.Access to domain 'testescripts' for user 'weblogic' denied Use dumpStack() to view the full stacktrace

Este problema ocorre porque a senha definida pelo nodemanager no domínio está diferente da senha de administração do domínio. A solução para o problema é alterar a senha do nodemanager no Console de Administração do Weblogic e colocá-la igual a senha utilizada para gerenciar o domínio.

Para fazer isso no console de administração do weblogic altere a senha do nodemanger navegando em:

Na árvore de navegação (Domain Structure) clique no nome do domínio > Security > Advanced

Procure por "NodeManager Username", "NodeManager Password" e "Confirm NodeManager Password" e altere a senha para ser igual à senha de administração do domínio. Salve e ative as configurações. Reinicie o nodemanager.

Pronto o script deve funcionar corretamente. Se o problema persistir, verifique no nodemanager.domains se o domínio onde está o servidor que deve ser controlado está registrado corretamente.

[]s

JBoss Seam - Configuração de ambiente

Estou começando alguns estudos sobre JBoss Seam. Já a alguns anos utilizo struts2 e previamente webwork, que é muito parecido com struts2 e no qual ele foi inspirado e utilizado como base. Ultimamente tenho visto muitos desenvolvedores que considero de alta qualificação falarem muito bem do JBoss Seam e por isso resolvi fazer alguns estudos e o primeiro desafio nestes casos é reunir tudo o que precisamos para configurar o ambiente de desenvolvimento para poder fazer alguns testes e aprofundar nos estudos. Neste post eu coloco os links de downloads que efetuei para deixar o ambiente pronto para trabalhar com o Seam.

Os softwares que utilizo para esta configuração são:
*Eclipse Galileo.
*JBoss 5.1.
*JBossTools para eclipse galileo. Utilizei o site configurado no eclipse galileo. A configuração que funcionou melhor no meu caso foi a Development. O update site é: http://download.jboss.org/jbosstools/updates/development/
*Seam 2.0.2.SP1 - Estou usando o 2.0 pois a maioria da documentação, atualmente, cobre essa versão.
*Mysql 5.1. - Baixei com o gerenciador de pacotes do Ubuntu.Foi necessário baixar também o driver JDBC do Mysql para configurar no JBoss Tools no eclipse.

Depois de baixar todos os softwares basta abrir o eclipse e criar um novo projeto do Seam. Alguns wizards irão aparecer para configurar os ambientes do JBoss App Server,JBoss Seam e Base de dados o driver do banco utilizado será necessário e a criação de uma base de dados com usuário e senha para utilizar durante os estudos. Com isso em mãos não tem segredo e depois é só começar a conhecer as ferramentas do JBoss Tools para começar os estudos.

Minha primeira impressão com o Seam foi bastante encorajadora. O ambiente do JBoss Tools parece bem amigável e fornece alguns wizards interessantes que facilitam e agilizam o desenvolvimento.
[]s

Weblogic JMS - Parte II - Arquitetura JMS

Neste post, faço um resumo da arquitetura de JMS, que é definido pelo item 2 da especificação JMS 1.1.

O item 2.2 define os possíveis participantes de uma aplicação JMS:
• Cliente JMS - Cliente JMS que utiliza linguagem java.
• Cliente não-JMS - Possíveis clientes JMS de uma aplicação escritos utilizando uma linguagem proprietária do provider. Como exemplo pode-se citar um cliente do IBM MQ escrito utilizando uma API proprietária do produto.
• Mensagens - Estas são as mensagens postadas e consumidas no MOM(Message Oriented Middleware).
• Provider JMS - Este é o MOM em si que pode fornecer serviços adicionais à especificação para seus clientes, como é o caso da maioria dos providers.
• Objetos Administrativos - São objetos pré-configurados no provider para facilitar a vida dos clientes, usualmente os objetos são ConnectionFactory e Destinations, estes objetos são registrados na árvore JNDI do servidor por default ou pelos administradores do MOM utilizado.

O modelo de Administração definido é o que proporciona interoperabilidade das aplicações escritas em JMS, isso porque os objetos ConnectionFactory e Destinations são padronizados e as APIs de acesso a estes recursos, fornecidas usualmente pelos providers, disponibilizam interfaces padrão para sua utilização.
ConnectionFactory - Objeto utilizado por clientes para criar uma conexão com o provider utilizado.
Destination - Objeto que o cliente usa para especificar o destino de envio ou recebimento de mensagens.
Estes objetos devem ser disponibilizados na árvore JNDI(Java Naming and Directory Interface) do servidor(JNDI Namespace), possibilitando acesso padronizado através da API padrão de java. Conforme imagem abaixo tirada da especificação JMS 1.1.

Conforme mencionado anteriormente existem dois tipos de mensagens que podem ser utilizadas conforme a especificação: Point-to-Point ou Publish/Subscriber Messages.

A especificação define então algumas APIs que possibilitam a utilização do tipo de mensagem desejado e ainda um conjunto de interfaces que abstrai essa implementação, conforme o quadro abaixo, retirado da especificação, ilustra.

Segue uma breve definição dos objetos da interface comum:

• ConnectionFactory - Objeto administrativo utilizado pelo cliente para criar uma conexão com o provider.
• Connection - uma conexão estabelecida com o provider.
• Destination - um destino de envio ou recebimento de mensagens.
• Session - um contexto criado com o provider para envio ou recebimento de mensagens.
• MessageProducer - Um objeto criado por uma sessão que efetivamente é utilizado apra envio de mensagens ao destino.
• MessageConsumer - Um objeto criado por uma sessão que é utilizado para consumir mensagens de um destino.

Conforme já foi mencionado, outros serviços não definidos pela especificação podem ser adicionados pelo fornecedor do provider e portanto, os modos de Administração, segurança, timers, dentre outros serviços, podem ser proprietários e definidos através de APIs de cada fornecedor do MOM(provider).

Na questão de acesso concorrente, a tabela mostrada abaixo, retirada da especificação, ilustra bem o modelo utilizado.

A especificação prevê ainda um modelo de Request/Reply para as mensagens poderem definir um estado de conversação. Para isso, é definido no header das mensagens um campo denominado JMSCorrelationID que pode ser utilizado para este fim.

[]s

Postgres SQL no Linux - Dicas úteis

Neste artigo estou reunindo informações úteis para um quickstart de Postgres com Linux, se vc estiver usando uma versão que use o yum ao invés do apt-get basta substituir o comando. As versões utilizadas nestes comandos são Postgres 8.4 e Ubuntu 9.10.

Os comandos devem ser dados utilizando um terminal do ubuntu.

Instalação da base de dados Postgres:

sudo apt-get install postgresql

Instalação da ferramenta de administração pgAdmin III:

sudo apt-get install pgadmin3

Iniciar o postgresql

sudo service postgresql start

Para cadastrar uma senha default do usuário postgres ou resetar a senha deste usuário que é o superusuário da base de dados utilizar:

sudo su postgres

Com o usuário do postgres no terminal execute o psql para conectar na base de dados de senhas do postgres e modificá-la:

psql -d template1

O terminal irá mostrar o console postgres:
#template1
Dê um alter table no terminal modificando a senha:

ALTER USER postgres WITH PASSWORD '${SUA_NOVA_SENHA}';

Para sair do console do postgres utilize \q no terminal conectado.

Caso seja necessário alterar permissão de acesso para a base criada deve-se editar o arquivo de configuração do postgres que por default fica no caminho: /etc/postgresql/8.4/main/pg_hba.conf no ubuntu e no red hat usualmente no /var/lib/pgsql

Reiniciar o postgres:

sudo /etc/init.d/postgresql-8.4 restart

Se quiser parar o postgresql:

sudo service postgresql stop

[]s

Weblogic JMS - Parte I - Overview de JMS

Comecei a revisar os conceitos de JMS do weblogic e por isso irei fazer uma série de postagens resumindo estes conceitos. A fonte principal de consulta para estes artigos será a especificação oficial da sun para JMS 1.1 e a documentação oficial de JMS do Oracle Weblogic Server 10.3.

JMS provê uma maneira padronizada para programas java criarem, enviarem, receberem e lerem mensagens de sistemas coorporativos de mensageria como Weblogic JMS Server, IBM MQ Series, Apache Active MQ dentre vários outros. A especificação provê então uma forma para comunicar com qualquer destes ambientes abstraídos de seu fornecedor, bastando, para isso, que o "Message Oriented Middleware" - Middleware orientado a mensagens escolhido implemente a especificação JMS 1.1 que é a abordada neste artigo.

JMS provê um conjunto de interfaces e padrões que definem como um cliente acessa os recursos de um Produto Orientado a Mensagens.

JMS prevê dois tipos básicos de mensagens "point-to-point" e "publish-subscribers". As mensagens point-to-point são mensagens enviadas para uma fila onde apenas um cliente irá publicar e somente um cliente irá receber e processar a mensagem, no modelo publish-subscriber é utilizado um tópico onde vários clientes podem se registrar para publicar e receber as mensagens. Para melhor ilustrar estes modelos basta pensarmos em um ambiente de call center por exemplo que é similar ao modelo point-to-point pois quando um atendente pega a ligação do usuário é feita uma ligação entre dois pontos. Já no modelo publish-subscriber é um modelo parecido com uma lista de discussão ou grupo da internet, onde um ou vários clientes podem postar uma mensagem que será recebida por todos os clientes que estiverem associados aquela lista. Posteriormente entrarei em mais detalhes e exemplos dos dois modelos.

O item 1.2.4 da especificação JMS 1.1 detalha um item bastante importante, listando os itens que não são definidos na especificação e que, portanto, cada fornecedor de produtos de mensageria implementam de forma proprietária ou em muitos casos nem fornece o serviço. Este itens incluem: Serviços de balanceamento de carga e tolerância à falhas, Notificação ou aviso de erros e problemas, Administração, Monitoramento, Segurança e Protocolo de comunicação. O Weblogic Server 10 possui todos estes serviços que podem ser considerados adicionais à especificação, mas que são fundamentais em um produto com qualide de serviços aceitáveis para grandes corporações.

O item 1.4 da especificação define que algumas APIs tem que ser compatíveis e possível de serem utilizadas em uma implementação JMS, e portanto todos os produtos que forem compatíveis com a especificação devem suportar os padrões: JDBC, componentes JavaBeans, EJB, JTA, JTS, JNDI e Java EE.

Neste primeiro artigo fiz um resumo do item 1 da especificação JMS 1.1 destacando seus principais pontos. No próximo irei tratar do modelo de arquitetura do JMS 1.1 que é definido no item 2 da especificação.

[]s