marcuscavalcanti.net » Java

Groovy + Grails

Marcus Cavalcanti — Fri, 29 Jul 2011 05:21:26 +0000

Desenvolver para WEB com Java nunca foi algo prazeroso, eu particularmente que sou oriundo de linguagens dinâmicas e de frameworks RoR like, nunca gostei de desenvolver com Java para WEB. Já tive a oportunidade de participar de projetos que utilizam frameworks como: Apache Beehive, Struts e Mentawaii. Assim como também tive a oportunidade de testar outros como: Wicket, Tapestry, Spring-MVC, etc. Desses, o que mais se aproximou de algo razoável foi o Spring-MVC, que parece nunca ser levado a sério pela própria SpringSource, que lançou a versão 3, mas nunca de forma realmente oficial, uma prova disso é que documentações a seu respeito são um tanto difíceis de serem achadas.

Quanto a Servlets (um mal necessário) e JSF (e suas N implementações), prefiro nem citar a minha opinião.

Paralelo a isso, aconteceu toda uma revolução na maneira de pensar em desenvolvimento para WEB com o lançamento do Ruby on Rails – framework WEB da linguagem Ruby – que foi um verdadeiro marco e que acabou impactando quase todas as outras linguagens, inclusive o próprio Java. A idéia do RoR é simples: facilitar, simplificar e tornar prazeroso o desenvolvimento para web. Seguir essa idéia sempre me pareceu uma boa opção.

Java como plataforma

Com todo esse advento dos novos frameworks WEB baseados no RoR e do crescimento de algumas linguagens como o próprio Ruby, Python e até linguagens de programação funcional, o Java, que já tem um estigma de ser uma linguagem complexa e que demora a evoluir, acabou perdendo força na comunidade como linguagem, mas em compensação passou a ser mais notada como plataforma, principalmente por causa do poder da JVM e das possibilidades que a mesma trás, com isso alguns projetos interessantes como Jython e JRuby surgiram e esses projetos nada mais são do que outras linguagens rodando em cima da JVM, ou seja, é possível desenvolver código Python e no final o mesmo virar byte-code e ser executado pela JVM.

E é nesse ponto que eu quero chegar, o assunto do próximo tópico.

Groovy

Groovy é uma nova linguagem, que roda em cima da JVM e que foi pensada de uma forma para ser dinâmica, simples e enxuta e ainda com a vantagem de poder se usar as API’s do Java.

Fora isso, foram criadas API’s específicas do próprio Groovy que facilitam muito o uso de alguns recursos/api’s do Java, como: coleções, mapas, strings, arquivos, etc.

A grande diferença do Groovy para o Java, é que o Groovy é uma linguagem de tipagem dinâmica, o que inicialmente pode ser um perigo para programadores habituados com Java, mas depois desse “trauma” inicial, a linguagem se mostra extremamente poderosa através de recursos como a possibilidade de se definir DSL’s.

Outra possibilidade interessante, é que é possível construir scripts com a linguagem Groovy, o que é uma verdadeira mão na roda para criação de rotinas de automatização, builds, etc.

Grails

Grails é um framework Groovy para WEB baseado no RoR e que tenta resolver todos os problemas já citados da burocracia de se desenvolver para WEB com Java.

Dentro do “pacotão” do Grails, já vem embutidos recursos como: injeção de dependência, mapeamento objeto relacional, segurança, testes (unitários e funcionais), validações, etc. Além do que, o framework é completamente focado em uma abordagem rich domain, diferentemente de outros frameworks.

Outro recurso muito interessante são os plugins, que são como mini-aplicações que podem ser instaladas dentro do Grails de acordo com a sua necessidade. Atualmente existem muitos plugins disponíveis no repositório do Grails e que atendem as mais variadas necessidades.

O framework é todo baseado em convenções e dispensa o uso de complexos arquivos XML para fins de configurações, o que no final das contas acaba sendo mais um fator para facilitar e agilizar o desenvolvimento, pois dessa maneira a equipe de desenvolvimento acaba ficando focada no que realmente interessa, que são os requisitos de negócio.

Porque escolhi Groovy+Grails

Antes de mais nada, escolhi por todos os motivos apresentados anteriormente, talvez até não tivesse toda essa visibilidade no começo do projeto, mas como o projeto novo não apresentava desafios muito grandes e ao mesmo tempo não era tão crítico, pensei que uma boa maneira em deixar minha equipe motivada seria investir em uma nova tecnologia.

Fora o fato, que como a equipe tinha experiência com Java, na pior das hipóteses, no caso da não adaptação da equipe com o Groovy, poderíamos usar códigos Java dentro do projeto, já que a linguagem permite isso, ou seja, foi um risco, mas um risco controlado e calculado.

Outro fator que contou muito para escolha dessa dobradinha, foi que passamos a adotar uma abordagem mais ágil e interativa com a presença mais próxima do cliente junto ao time de desenvolvimento e isso significava que deveríamos ter algo entregável toda semana, que foi a periodicidade que definimos para as nossas iterações. A adoção do Groovy e Grails agilizaria nosso tempo de desenvolvimento, consequentemente conseguiríamos produzir mais features em menos tempo, que era exatamente o que estavámos buscando.

Qual tem sido a minha experiência

A melhor possível. Quando eu digo a melhor possível, é porque tem sido melhor que o esperado, mas obviamente, como tudo na vida, tem seus prós e contras.

Um dos pontos positivos, foi que a curva de aprendizado foi bem menor do que o esperado, ou seja, a equipe entrou no “ritmo” do framework bem rápido.

Outro ponto positivo, é a abordagem do framework de ser realmente orientado a objetos, favorecendo uso de uma modelagem focada em domínio rico e testes. Para toda entidade, service, ou controller novos criados, automaticamente um teste já é criado, ou seja, isso torna claro para o desenvolvedor, que seguindo os conceitos do TDD, o mais aconselhável é que os testes sejam criados antes da implementação, pois só dessa maneira o design do seu código será influenciado para se tornar mais coeso, menos acoplado e com as camadas bem definidas de acordo com a sua responsabilidade dentro do contexto.

Como o framework é full-stack e baseado em convenções, configurar um projeto e rodar tem o custo quase zero, ou seja, muito pouco tempo é disperdiçado.

Como nem tudo são flores, tivemos um impacto inicial com a curva de aprendizado de uma linguagem dinâmica (para quem não tinha prática com isso), fora os novos conceitos do próprio framework. Mas volto a repetir: o impacto foi menor que o previsto. Para resolver esse tipo de problema, adotamos algumas medidas como: pair programming e um grupo de estudo interno para troca de conhecimento, onde cada um deveria mostrar algum tópico em que já tivesse mais avançado, para o restante.

Outro impacto que tivemos foram de algumas peculiaridades do framework, que apesar de ser muito bom, ainda apresenta alguns pequenos bugs (e até manhas) que demoram a serem notados. Como o framework está em evolução e ainda em versão 1.*, é normal que esteja um pouco imaturo, portanto não o recomendaria ainda para um projeto mais complexo e crítico.

IDE’s ainda são um problema quando se pensa em Groovy + Grails, na verdade, existe uma IDE muito boa, mas que é paga e não é o Eclipse, IDE no qual a maioria dos desenvolvedores Java já está acostumada. Essa IDE é o Intellij da Jet Brains, no qual já testei e realmente é a melhor opção no mercado.

Conclusão

Recomendaria Groovy+Grails se você tem uma visão semelhante a minha sobre desenvolvimento para WEB com Java e também se você tiver a oportunidade de usá-los em algum projeto sem muita criticidade e complexidade (apesar de existirem alguns cases), mas é importante mensurar sempre os riscos da adoção de algo novo, pois no final isso pode ser irreversível.

BDD com JBehave

Marcus Cavalcanti — Fri, 08 Jan 2010 19:39:55 +0000

Conforme prometido no tópico anterior, irei mostrar o conceito de BDD através da utilização do framework JBehave, que é o framework de BDD mais famoso para Java e que foi desenvolvido pelo Dan North, o idealizador deste conceito.

Antes de mais nada, vamos citar alguns conceitos importantes de BDD.

Estórias e Cenários

BDD é baseado em estórias e cenários, e para criarmos ambos, vamos seguir alguns padrões pré-definidos por autores de BDD. Uma vez que BDD é focado em comportamento e sequência, as estórias e cenários devem ter um formato rígido para que as ferramentas consigam entendê-los e interpretá-los.

As estórias, possuem o seguinte formato:

As I [X]
I want [Y]
so that [Z]

E os cenários possuem o seguinte formato:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Ou seja, isso quer dizer que devemos pensar em nossos requisitos de maneira que possam ser escritos baseados nessa convenção.

O JBehave é originalmente escrito para entender estórias em inglês, entretanto como BDD é focado em pessoas (stakeholders) e na descrição de situações reais, faz muito mais sentido semanticamente que as estórias e cenários sejam escritos em português e para resolver isso, usei uma contribuição do Emerson Macedo para que os cenários possam ser escritos e entendidos em português pelo JBehave.

Começando com o JBehave

O primeiro passo para utilização do JBehave, é fazer download do JAR do projeto e incluí-lo no classpath do seu projeto.

O próximo passo é escrever a estória juntamente com o cenário e para tal resolvi criar um exemplo simples para que o entendimento do conceito possa ser casado através do código a ser desenvolvido.

O exemplo escolhido é baseado no requisito: Compra de produtos em promoção com aviso por email. E é isso que nosso cenário BDD deve descrever.

Por questão de organização, resolvi quebrar a estória em 3 cenários diferentes, onde a primeira parte representa a verificação de produtos em promoção, a segunda representa a compra desses produtos e o terceiro é a finalização da compra e o envio de email. Então, a estória e os cenários ficaram assim:

Compra de produtos em promoção com aviso por email
 
Narrativa:
Como um usuário
Eu quero comprar produtos em promoção
E então receber um email de confirmação
 
Cenário: Verificar produtos em promoção
Dado Que uma loja possui 10 produtos
E Que 5 estão em promoção
Quando Eu verifico quais estão em promoção
Então Preencho minha sacola apenas com produtos em promoção
 
Cenário: Comprar produtos em promoção
Dado Que minha sacola de compras está preenchida com 5 produtos em promoção
Quando Eu verifico o somatório de produtos
Então Devo ter somente um total de 500 reais em produtos
 
Cenário: Enviar email
Dado Que minha sacola está preenchida de produtos
Quando Enviar um email de confirmação
Então Devo receber o status do envio "true"

A primeira linha do arquivo texto representa o título da nossa estória, o requisito de fato. A narrativa é um resumo do que essa estória deve cumprir e a seguir vem os três cenários, que no caso são as três etapas da estória.

É importante notar, que as palavras chaves em inglês (Given, When, Then, And) foram substituídas por palavras em português (Dado, Quando, Então, E).

Esse arquivo texto deve ser salvo com a extensão *.cenario e o seu nome está diretamente ligado a classe que irei criar no passo a seguir, que no caso é a classe que representa a estória e a associação com os cenários.

Criando a classe que irá comportar os cenários

Nesse passo irei criar a classe que irá apontar os cenários que compõe a estória e essa classe deve extender a classe Scenario do JBehave. Dessa forma, a classe ficaria assim:

PrecoPromocaoTeste.java

```
package scenario1;
```
```
 
```
```
import scenario1.steps.CompraSteps;
```
```
import scenario1.steps.EmailSteps;
```
```
import scenario1.steps.PromocaoSteps;
```
```
import scenario1.util.PtBRScenario;
```
```
 
```

public class PrecoPromocaoTeste extends PtBRScenario {

```
	public PrecoPromocaoTeste() {
```

           addSteps(new PromocaoSteps());

```
           addSteps(new CompraSteps());
```
```
           addSteps(new EmailSteps());
```
```
	}
```
```
}
```

No exemplo acima, estou extendo a classe PtBRScenario só para que a estória e o cenário sejam escritos em português, mas essa classa herda a classe Scenario como descrito anteriormente.

No construtor da classe, inclui os passos que a estória deve seguir para ser satisfeita e como quebrei a estória em três pedaços, precisei incluir três passos sequenciados.

Criando os passos da estória

Como a estória foi quebrada em três partes, se faz por necessário a criação de 3 classes que irão representar os passos da estória e todas essas classes devem herdar a classe Steps do JBehave.

Pela ordem definida na nossa classe de cenário, vamos aos passos:

PromocaoSteps.java

```
package scenario1.steps;
```
```
 
```
```
import java.util.List;
```
```
 
```
```
import junit.framework.Assert;
```
```
 
```

import org.jbehave.scenario.annotations.Given;

import org.jbehave.scenario.annotations.Then;

import org.jbehave.scenario.annotations.When;

```
 
```
```
import scenario1.entity.Loja;
```
```
import scenario1.entity.Produto;
```
```
import scenario1.util.PtBRSteps;
```
```
import scenario1.vo.Sacola;
```
```
 
```

public class PromocaoSteps extends PtBRSteps {

```
	Loja loja 		= new Loja();
```
```
	Sacola sacola 	= new Sacola();
```
```
	List<Produto> listaProdutoPromocao;
```
```
	int quantidadeProdutoPromocao;
```
```
 
```

	@Given("Que uma loja possui $quant produtos")

	public void populaLoja(Integer quantidade) {

```
		loja.inicializaProdutos(quantidade);
```
```
	}	
```
```
 
```

	@Given("Que $quant estão em promoção")

	public void informaProdutosPromocao(Integer quantidade) {

		loja.colocaProdutosPromocao(quantidade);

		quantidadeProdutoPromocao = quantidade;

```
	}	
```
```
 
```

	@When("Eu verifico quais estão em promoção")

	public void verificaProdutosPromocao() {

		listaProdutoPromocao = loja.retornaProdutosPromocao();

```
	}
```
```
 
```

	@Then("Preencho minha sacola apenas com produtos em promoção")

```
	public void populaSacola() {
```

		sacola.populaSacola(listaProdutoPromocao);

```
 
```

		Assert.assertEquals(listaProdutoPromocao.size(), quantidadeProdutoPromocao);

```
	}
```
```
}
```

CompraSteps.java

```
package scenario1.steps;
```
```
 
```
```
import java.util.ArrayList;
```
```
import java.util.List;
```
```
 
```
```
import junit.framework.Assert;
```
```
 
```

import org.jbehave.scenario.annotations.Given;

import org.jbehave.scenario.annotations.Then;

import org.jbehave.scenario.annotations.When;

```
 
```
```
import scenario1.entity.Produto;
```
```
import scenario1.util.PtBRSteps;
```
```
import scenario1.vo.Sacola;
```
```
 
```

public class CompraSteps extends PtBRSteps {

```
	Sacola sacola 				= new Sacola();
```
```
	double somatorioProdutos 	= 0d;
```
```
 
```

	@Given("Que minha sacola de compras está preenchida com $quant produtos em promoção")

	public void verificaSacola(Integer quantidade) {

		List<Produto> listaProduto = new ArrayList<Produto>();

```
 
```
```
		for (int i=1; i<=quantidade; i++) {
```
```
			Produto produto 	= new Produto();
```

			produto.preco 		= Math.round(Math.random()*100);

```
			produto.emPromocao 	= true;
```
```
 
```
```
			listaProduto.add(produto);
```
```
		}
```
```
 
```
```
		sacola.populaSacola(listaProduto);
```
```
	}
```
```
 
```

	@When("Eu verifico o somatório de produtos")

	public void verificaTotalProdutosSacola() {

		for ( Produto produto : sacola.retornaProdutos() ) {

			somatorioProdutos = produto.preco + somatorioProdutos;

```
		}
```
```
	}
```
```
 
```

	@Then("Devo ter somente um total de R$ $total reais em produtos")

	public void validaSacola(double totalProduto) {

		if ( somatorioProdutos > totalProduto )

			Assert.fail("Total de produtos é acima de R$ 500");

```
	}
```
```
}
```
```
rpe>
```
```
 
```
```
<strong>EmailSteps.javastrong>
```
```
<pre lang="java" line="1">
```
```
package scenario1.steps;
```
```
 
```

import static org.jbehave.Ensure.ensureThat;

```
 
```

import org.jbehave.scenario.annotations.Given;

import org.jbehave.scenario.annotations.Then;

import org.jbehave.scenario.annotations.When;

```
 
```
```
import scenario1.util.PtBRSteps;
```
```
import scenario1.vo.Sacola;
```
```
 
```

import com.guilhermechapiewski.fluentmail.email.EmailMessage;

import com.guilhermechapiewski.fluentmail.transport.EmailTransportConfiguration;

```
 
```

public class EmailSteps extends PtBRSteps {

```
	Sacola sacola 		= new Sacola();
```
```
	Boolean statusEnvio = false;
```
```
 
```

	@Given("Que minha sacola está preenchida de produtos")

```
	public void verificaSacola() {
```
```
		System.out.println("Lista cheia..");
```
```
	}
```
```
 
```

	@When("Enviar um email de confirmação")

```
	public void enviaEmail() {
```

		EmailTransportConfiguration.configure("localhost", false, false, "", "");

```
 
```
```
		new EmailMessage()
```

	    	.from("eusou@marcuscavalcanti.net")

```
	    	.to("eusou@marcuscavalcanti.net")
```
```
	    	.withSubject("Testando BDD")
```

	    	.withBody("Testando terceiro cenário e o final da estória.")

```
	    	.send();
```
```
 
```
```
		statusEnvio = true;
```
```
	}
```
```
 
```

	@Then("Devo receber o status do envio \"$retorno\"")

	public void recebeStatusEnvio(String retorno) {

		ensureThat(statusEnvio.toString().equals(retorno));

```
	}
```
```
}
```

Nos exemplos acima, que representam os passos de um cenário, é importante notar que os métodos seguem a ordem definida no arquivo texto, assim como todos são anotados com as palavras chaves correspondentes, no caso Given, When, And, Then. As anotações recebem como parâmetro as frases descritas no arquivo texto, excluindo apenas as palavras chaves no começo da frase, que estão devidamente representadas pelas anotações.

Os parâmetros são identificados com o formato $variavel, e uma vez que usamos esses parâmetros, devemos também colocá-los na assinatura dos métodos. Esses parâmetros são automaticamente capturados pelo JBehave através do uso de expressões regulares.

Executando o exemplo

Para executar o exemplo deve-se executar a classe que extende a classe Scenario do JBehave, nesse caso seria a classe PrecoPromocaoTeste.java, e para acompanhar os resultados, eu utilizo a integração do Eclipse com o JUnit, através de uma view própria da IDE.

No exemplo, usei ainda algumas classes auxiliares criadas especificamente para o exemplo, mas que não irei mostrar aqui os seus códigos para não tornar o tópico extenso demais. De qualquer forma, ao final desse tópico botarei um link para download do projeto no Eclipse que contém todos os códigos.

Observações finais

Um dos problemas que eu notei no JBehave é em relação a parametrização de alguns valores no arquivo texto para o código Java, em alguns casos isso pode se tornar um trabalho sacal e pouco produtivo, mas acredito que com a evolução do framework esse problema será resolvido.

Algumas pessoas utilizam alternativas variadas para resolver esse problema, como por exemplo criar o valor dos parâmetros diretamente como atributos nas classes que representam os passos. Eu particularmente não gosto dessa abordagem, pois acredito que isso faz com que os arquivos que descrevem os cenários percam seu valor e esses arquivos são essencial para utilização e sentido do BDD.

No exemplo citado, usei ainda algumas bibliotecas como FluentMailApi, Mail e Activation da JavaMail e Hamcrest. Essas bibliotecas servem basicamente para o envio de email e uso mais aperfeiçoado de expressões regulares por parte do JBehave.

Para finalizar, é importante citar que as classes do meu negócio (Sacola, Usuario, Loja, etc) foram construídas baseadas no meu requesito, no meu cenário, que foi a primeira etapa a ser elaborada na construção do exemplo.

Download

Para download do projeto completo no Eclipse, basta clicar aqui.

Entendendo como funciona a arquitetura do Weblogic Server em ambientes clusterizados

Marcus Cavalcanti — Tue, 24 Nov 2009 16:50:07 +0000

Antes de mais nada, gostaria de ressaltar que esse post não tem o intuito de ensinar ou mostrar o passo-a-passo para a criação de um ambiente clusterizado com o Weblogic Server, na verdade o intuito é mostrar como é e como funciona essa arquitetura, usando um exemplo prático criado para esse propósito específico. Para criação e configuração de um ambiente clusterizado, indico a documentação da Oracle/BEA, na qual estarei citando os links ao final do post.

Domínio

Quando trabalhamos em um ambiente de desenvolvimento, basicamente o que temos que nos preocupar é referente a criação de um domínio. Um domínio nada mais é que um conjunto de recursos e serviços que fisicamente são mantidos através de arquivos.

A parte principal de um domínio chama-se Administration Server, que é uma instância de um Weblogic Server responsável por manter e configurar seus recursos. Todo esse gerenciamento do Adminstration Server é feito através do Admin Console, que por sua vez é uma aplicação que é deployada no seu Administration Server e que será responsável por fornecer uma interface gráfica para que você possa gerenciar seu domínio, ou seja, toda a configuração feita pelo Admin Console é baseada em XML e é ele quem gerencia esses arquivos.

É através do Administration Server que você faz o deploy/undeploy das suas aplicações, porém em um ambiente de produção, ou até mesmo de homologação, o mais indicado é que tenhamos nossas aplicações em um servidor a parte, que são chamados de Managed Servers.

Managed Servers

Uma instância de um Weblogic Server, que não é uma instância do Administration Server, é chamada de Managed Server, é no Managed Server onde suas aplicações e recursos serão deployados de fato, deixando para o Administration Server apenas a responsabilidade de gerenciá-los.

São os Managed Servers que hospedam todos os componentes e recursos que constituem uma aplicação, e toda vez que um Managed Server é inicializado, ele se conecta com o Administration Server para obter informações de configuração e deployment.

Cluster. O quê é e por quê usar?

Em ambientes de produção é normal que existam certas preocupações que não ocorrem com ambientes de desenvolvimento, como alta disponibilidade das aplicações e balanceamento de carga.

Imagine que ocorra qualquer problema na máquina onde a sua aplicação está deployada? O quê fazer? Para não ficar a mercê desse tipo de problema, o correto é pensar em uma estrutura em que sua aplicação possa ser replicada em N instância de servidores em máquinas diferentes, onde caso uma máquina dê problema, a outra assume e assim sucessivamente.

Outro problema comum é a sobrecarga de uma aplicação. Um cenário normal em aplicações web é o acesso de muitos usuários e consequentemente o processamento a exaustão das máquinas onde essas aplicações estão deployadas, isso por muitas vezes pode ocasionar um estouro de processamento ou até mesmo um tempo de resposta maior para o usuário. E como fazer para resolver esse problema? A resposta é através do balanceamento de carga.

Para resolver esses tipos de problemas foi criada uma estrutura cuja o nome é Cluster. Um Cluster é um conjuto de computadores que trabalham de forma conjunta cujo objetivo é fazer com que todo o processamento da aplicação seja distribuído a N computadores, mas de forma que pareça com que eles sejam um computador só.

Cluster e Managed Servers

Um Cluster de Weblogic Server corresponde a múltiplas instância de Weblogic Server que estão trabalhando e rodando simultaneamente com o objetivo de prover escalabilidade e disponibilidade.

Ou seja, um Cluster é um conjunto de Managed Servers, e cada Managed Server representa um nó de um cluster.

Quando se pensa em uma arquitetura usando Clusters, é normal que se pense em mais de uma máquina, afinal não faz muito sentido ter um Cluster com uma máquina, pois caso essa máquina pare de funcionar, todas as aplicações também irão parar.

A relação Managed Servers, Machines e Domínio

Partindo do princípio que um Cluster deve necessariamente ter mais de uma máquina, chegamos ao conceito de “Machines” do Weblogic Server.

Uma “machine” é exatamente uma máquina, um computador físico, e essa máquina pode ter mais de um managed server, ou seja, pode ter mais de uma instância do Weblogic Server rodando ao mesmo tempo. É óbvio que nesse caso teríamos que ter essas duas instâncias rodando em portas diferentes.

Dessa forma, chegamos a seguinte associação: Domínio -> Administration Server -> Cluster -> Machine -> Managed Server.

Node Manager

Quando falamos a nível de máquina (machine), devemos falar também dos Node Managers. Um Node Manager não está associado a um domínio, está associado a uma máquina, já que uma máquina pode ter mais de um Managed Server.

Um Node Manager é uma aplicação standalone responsável por gerenciar Managed Servers em uma máquina (machine) remota. Através do Node Manager é possível inicializar, parar e re-startar instâncias do Administration Server e dos Managed Servers de uma máquina remota.

Multi-cast Address

Em um ambiente clusterizado, precisamos ter N computadores trabalhando de forma conjunta de forma que isso seja transparente, mas quando usamos recursos como sessões, ou até mesmo conexões distribuídas, precisamos que isso também seja feito de forma distribuída, sem que seja necessário por exemplo criar uma sessão para cada Managed Server.

Isso é feito através do multi-cast address, que é um IP associado a um cluster, que por sua vez irá informar esse IP para seus Managed Servers para que os mesmos possam usar um único IP para fazer esse tipo de compartilhamento.

Juntando tudo

Para dar uma visão mais clara de toda essa arquitetura e quem está associado a o que, resolvi criar um diagrama que mostra todos os elementos citados acima e associação/relação entre eles.

No exemplo usei ainda o Apache como Servidor Web, que será a porta de entrada de tudo, será ele que irá receber as requisições HTTP, fazer o balanceamento de carga e delegar as responsabilidades para os Managed Servers. Será o Apache ainda o responsável por identificar e servir conteúdo estático sem que seja necessário passar pelo Cluster.

Diagrama

clique para ampliar

Mais Informações

Weblogic Server
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/admin.html

Understanding Cluster Configuration
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/config.html

Understanding Weblogic Server Clustering
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/cluster/overview.html

Setting Up Weblogic Cluster
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/setup.html

Using Node Manager
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/server_start/nodemgr.html

Node Manager Architecture
http://download.oracle.com/docs/cd/E13222_01/wls/docs81b/adminguide/nodemgr.html

Configure Apache HTTP Server
http://download.oracle.com/docs/cd/E15051_01/wls/docs103/plugins/apache.html

Dica rápida: recuperando um domínio corrompido no Weblogic

Marcus Cavalcanti — Wed, 11 Nov 2009 16:54:03 +0000

Essa é uma dica rápida para quem trabalha com aplicações em cima do Weblogic.

Um domínio Weblogic pode ser corrompido por diversos motivos, como: domínio ser encerrado de forma forçada ( com um kill -9, por exemplo), máquina ser desligada de forma repentina, falta de luz, etc. Quando isso acontece, seu domínio que estava rodando pode ser corrompido, e com isso a seguinte mensagem é retornada ao tentar iniciá-lo novamente:

Server cannot be started.   The server process cannot be started, or terminated abruptly. Check the start script.

Para resolver isso é muito simples, basta remover todas as pastas build pré-existentes (são geradas automaticamente pela seu Workshop, quando a aplicação é compilada) e em seguida basta fazer um start do seu domínio novamente.

Outra dica, é que antes de tentar fazer o deploy das aplicações em cima desse domínio novamente, que antes faça um undeploy (usando o console) das mesmas, pois se o domínio foi encerrado de forma forçada, as aplicações ainda estarão lá deployadas e caso você tente novamente, provavelmente não conseguirá.

Procurei sobre isso nos forums da Oracle e não achei nada, então fica aí a dica, pois isso evita que você tenha que re-criar e configurar seu domínio novamente.

Usando o HermesJMS com JDK 1.6 no Weblogic

Marcus Cavalcanti — Wed, 08 Jul 2009 20:41:05 +0000

O HermesJMS é uma ferramenta muito útil para dar suporte ao desenvolvimento de aplicações que trabalham com JMS (menssageria), ou seja, para quem trabalha com integrações, processos e SOA é de grande utilidade.

Com o HermesJMS é possível publicar mensagens, remover, ver o conteúdo das mensagens publicadas, a quantidade, dentre outras funcionalidades. Eu diria que o HermesJMS está para JMS como o soapUI está pra Web Services.

Só que existe um pequeno probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2. O HermesJMS foi construído com a JVM 1.6 e o Weblogic 10.2 roda com a JVM 1.5, portanto quando tentamos acessar resources JMS configurados em um servidor Weblogic temos um probleminha com o ClassLoader, segundo bug relatado nesse link.

Geralmente para resolução desse problema, quando eu ia usar o Hermes, eu mudava a minha váriavel ambiente JAVA_HOME para apontar para o JDK 1.5, para agilizar esse processo pode ser feito um Shell Script que seta essa varíavel de ambiente apontando para o JDK 1.5 e abrindo o HermesJMS logo em seguida, mas existe uma solução melhor e mais limpa para isso, que é setando uma propriedade na inicialização do HermesJMS, seguem os passos necessários:

1) Entrar no diretório de instalação do HermesJMS, no meu caso é /opt/HermesJMS
2) Editar o arquivo hermes.sh que fica dentro do diretório bin
3) Ir para a última linha desse arquivo e adicionar a propriedade: -Dsun.lang.ClassLoader.allowArraySyntax=true

Dessa forma, a última linha do arquivo /bin/hermes.sh ficaria assim:

"$JAVACMD" -XX:NewSize=256m -Xmx1024m -Dsun.lang.ClassLoader.allowArraySyntax=true $HERMES_OPTS -Dhermes.home=$HERMES_HOME -Dhermes=$HERMES_CFG -Dhermes.libs=$HERMES_LIB_PROPERTY -classpath $LOCALCLASSPATH hermes.browser.HermesBrowser

Esse pequeno workaround corrige esse probleminha de incompatibilidade entre o HermesJMS e o Weblogic 10.2 e nos permite usar o HermesJMS com o JDK 1.6.

Mostrando mensagens de log no stdOut (console) do Weblogic

Marcus Cavalcanti — Fri, 27 Mar 2009 04:17:26 +0000

Essa é uma dica bem rapidinha, que na verdade estou postando, pois não achei nada no Google muito relevante a respeito. Como imagino que existem pessoas com o mesmo probleminha, então segue a dica logo abaixo.

Na aplicação web do projeto que estou trabalhando, nós fazemos o uso da API Commons Logging do Apache para poder fazer logging da aplicação, só que para o log aparecer corretamente no console existe um pequeno “macete”, que por incrivel que pareça não diz com mais detalhes na documentação do Weblogic.

O probleminha era, que por mais que eu fizesse o seguinte:

```
public class SovWS {
```
```
 
```

	private static Log log =  LogFactory.getLog("SOV-"+SovWS.class);

```
 
```
```
	@WebMethod
```

	public SaveMetaResponseDocument saveMeta(SaveMetaRequestDocument request) {

		log.info(this.getClass() + " iniciando a nova meta");

```
               ....
```
```
        }
```
```
}
```

Eu não conseguia fazer com que a mensagem de log aparecesse no console do Workshop, ainda que tudo estivesse correto.

Para resolver é muito simples, basta ir nas propriedades do projeto, ir nos facets do projeto e verificar se a extensão Weblogic Integrated Commons Logging está como um facet do projeto, se não estiver, está aí o problema e para resolver basta adicionar esse novo facet.

Para ter certeza que está tudo certinho, sugiro abrir o arquivo weblogic-application.xml e verificar se a seguinte configuração está presente:

>
    >wls-commonslogging-bridge>
    >1.0>
    >true>
>

Se a seguinte configuração estiver presente, pronto, tudo ok! Agora o log deverá aparecer no console sem problemas.

PS: Só para ressaltar que essa dica é válida para ambiente de desenvolvimento.