Porque configuração programática não é uma idéia tão boa assim

23 de julho de 2007 6 respostas

eliziario 23 de julho de 2007

Eu tenho um MDB do qual, que por motivos que não vem ao acaso, não me interessa ter mais de uma instância em cada nó de um cluster JBoss. Ou seja, preciso de alguma maneira de dizer ao servidor que não quero mais que uma instância no pool de instâncias de cada deployment no cluster. Tudo blz, mas configuração do pool de instâncias de EJB é dependente de implementação e portanto não é padronizado, o que nos força a usar recursos proprietários do app-server que estivermos usando.

A maneira programática de fazer no jboss é
@PoolClass (value=“org.jboss.ejb3.StrictMaxPool”, maxSize = 1, timeout=9999999)

Ou seja, como o que eu quero é uma configuração eu emporcalho o meu MDB com um import de uma classe concreta e ainda por cima do JBoss. O que mostra o quanto a idéia de configuração programática pode ser perigosa e contra-producente em algumas situações.
Já usando o descritor jboss, meu bean fica limpinho, eu configuro ele numa boa e todos ficam felizes. Se eu tiver que deployar no Weblogic é colocar mais um descritor e tudo continua ok.

<?xml version="1.0" encoding="UTF-8"?>

<javaee:jboss version="3.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee ../../schemas/jboss_5_0.xsd ">

<javaee:enterprise-beans> 

<javaee:message-driven>

<javaee:ejb-name>JobExecutorBean</javaee:ejb-name>

<javaee:pool-config>

<javaee:pool-class>org.jboss.ejb3.StrictMaxPool</javaee:pool-class>

<javaee:pool-max-size>1</javaee:pool-max-size>

<javaee:pool-timeout>99999999</javaee:pool-timeout>

</javaee:pool-config>

</javaee:message-driven>

</javaee:enterprise-beans>

</javaee:jboss>

Fica claro que a solução baseada em um descritor externo é mais clara e limpa. Pode-se até discutir que XML é verboso, mas para quem usa eclipse ou IntelliJ o recurso de code completion funciona perfeitamente. E uma coisa é o uso de XML, outra é o uso de descritores externos, nada impediria que usássemos YAML como linguagem dos descritores. Da mesma maneira, o relacionamento hierárquico das propriedades de configuração fica óbvio em um XML ou YAML, coisa que não acontece com uma lista de statements no meio do código java.

6 Respostas

urubatan 23 de jul. de 2007

O problema não é a forma de configurar qualquer coisa
o problema, como eu ja disse diversas vezes, é a necessidade de configurar …

Poder configurar é muito bom, ser obrigado a configurar, é uma m***

eliziario 23 de jul. de 2007

urubatan:
O problema não é a forma de configurar qualquer coisa
o problema, como eu ja disse diversas vezes, é a necessidade de configurar …

Poder configurar é muito bom, ser obrigado a configurar, é uma m***

Sim, mas nesse caso eu só precisei configurar porque precisava de algo que foge do default.

TheMask 23 de jul. de 2007

É exatamente por isso que ainda torço o nariz (ok, só um pouquinho) para annotations. Para mim, configuração deve ficar fora da classe a ser configurada. Se é em Java, em XML, em <olha só que bonitinha a minha nova linguagem de configuração>, são outros quinhentos. E XML, definitivamente, não é a minha preferência.

saoj 24 de jul. de 2007

Eu sempre vi Configuração Programática como sendo algo totalmente diferente de Annotations. Uma coisa é o oposto da outra…

Annotations espalha a configuração pelo código e força um rebuild total quando vc quer alterar alguma coisa.

Annotations atrela configuração a código. Annotations tem pouca flexibilidade.

A configuração programática que defendo é a configuração que usa uma linguagem de programação, seja ela Java, Groovy, BeanShell, Ruby, etc.

XML, assim como Annotation, não é linguagem de programação, apesar de que muitos gostariam que fosse. Não é melhor usar XML para o que ela foi feita (plataform-independ data) e usar uma linguagem de programação para a configuração ??? (Mais sobre isso nesse artigo do Martin Fowler!)

Recentemente no Mentawai fizemos uma coisa interessante que é o método getProperties dentro do ApplicationManager. Esse método vai carregar um arquivo properties, tentando primeiro fazer um HOSTNAME-appMgr.properties. Se não encontrar tenta o default appMgr.properties.

Isso é para aquelas configurações totalmente estáticas e burras que vc não quer deixar hardcoded dentro da configuração programática.

Por exemplo na máquina de testes eu tenho um BETAMACHINE-appMgr.properties com os dados do banco de testes e na máquina de produção eu tenho um PRODMACHINE-appMgr.properties com os dados do banco de produção.

Dessa maneira eu posso fazer o deploy do meu código em ambos os ambientes sem me preocupar em reconfigurar qualquer coisa…

Não configurar é 100 vezes melhor do que configurar, seja lá com o que, mas para certas coisas fica complicado fugir da configuração. Ex: DI, IoC, Transações, Autenticação, Autorização, Tratamento de Exeptions, etc.

Configuração num projeto web MVC tem um significado muito mais amplo do que descobrir pra qual JSP essa action vai jogar e quais são os parametros do pool de conexões…

chun 24 de jul. de 2007

Acho que a maneira que Java EE trouxe eh a melhor…

Configuracao via annotattions… COM a opcao de usar descritores XML… quem quer usa cada um… o melhor dos dois mundos… tem coisa q nao tem prq usar XML… ex: definir um sessionbean… pode ser usado com annotation tranquilamente…

e esse negocio de recompilar tudo é pura baboseira… hoje em dia faz-se deployment do war … e o IDE gera o war para voce…

Vejo annotations como algo muito util e poupa tempo… e sse negocio de ideologia de “configuracao 100% limpa” que seja usado por esses loucos por XML… enquanto tiver a opcao de configurar as opcoes padroes via annotations tudo fica mais lindo e produtivo

ps: estou falando no caso do uso de EJB’s…

Acho os XML’s do spring simplemente um CAOS… ainda mais em um sistema grande… dalhe spring annotations !

nao complicar uma coisa simples… e tmb se apioar nessa balela de “ai tenho que recompilar tudo” , como se voce fizesse tudo na mao… se vc usa o NetBeans… gerar seu war e fazer o deployment é tão complicado quanto apertar um botao “run”

Kenobi 24 de jul. de 2007

chun:
Acho que a maneira que Java EE trouxe eh a melhor…

Configuracao via annotattions… COM a opcao de usar descritores XML… quem quer usa cada um… o melhor dos dois mundos… tem coisa q nao tem prq usar XML… ex: definir um sessionbean… pode ser usado com annotation tranquilamente…

e esse negocio de recompilar tudo é pura baboseira… hoje em dia faz-se deployment do war … e o IDE gera o war para voce…

Vejo annotations como algo muito util e poupa tempo… e sse negocio de ideologia de “configuracao 100% limpa” que seja usado por esses loucos por XML… enquanto tiver a opcao de configurar as opcoes padroes via annotations tudo fica mais lindo e produtivo

ps: estou falando no caso do uso de EJB’s…

Acho os XML’s do spring simplemente um CAOS… ainda mais em um sistema grande… dalhe spring annotations !

nao complicar uma coisa simples… e tmb se apioar nessa balela de “ai tenho que recompilar tudo” , como se voce fizesse tudo na mao… se vc usa o NetBeans… gerar seu war e fazer o deployment é tão complicado quanto apertar um botao “run”

Concordo com o Chun e fora configuração, nem sei se entra nesse tema, pq seria definição, olhem o que aconteceu com o mapeamento do Hibernate, idéia oriunda do XDoclet .

Tirou um trabalho fenomenal e facilitou muito o entendimento do mapeamento, podendo esse ser feito diretamente nos pojos envolvidos.

Acho que a abordagem deve ser utilizada com racionalidade.

Válida a demonstração do tópico de quando “não utilizar” e à partir daí, segue o bom senso de atrelar ou não algo ao seu código.

Criado 23 de julho de 2007

Ultima resposta 24 de jul. de 2007

Respostas 6

Participantes 6

6 Respostas

Topicos relacionados