Archive for the ‘Java’ category

JBoss Seam no Tomcat

July 28th, 2008

EDIT: esse post é para o Seam 2. Utilizar o Weld (com Seam 3) no Tomcat ficou bem mais fácil, veja um post mais recente sobre o assunto.

Quem está começando a aprender JBoss Seam pode ter a impressão que ele roda apenas no JBoss AS, o que não é verdade. Devido à maioria da documentação ser provida pelo pessoal do JBoss é claro que tudo é feito tendo-se em mente o AS deles. Mesmo quem sabe ser possível rodar sobre outros ASs, muitas vezes não tem idéia de como fazê-lo.

O Seam em si não é um serviço no JBoss, mas sim um framework, o que possibilita sua utilização em vários ASs. Caso não seja usada nenhuma facilidade EE (ou mesmo algumas que o Seam cobre), é possível fazer o deploy de uma aplicação Seam até mesmo sobre um simples container web como o Tomcat e esse post sobre esse caso.

Sendo o Seam uma biblioteca, dificuldades em fazer deploy em containers se limitam a conflitos e dependências. Mas quem já usou Seam sabe da grande mão na roda que é o seam-gen para geração de scaffold (inclusa no JBoss Tools). O problema é que o scaffold gerado é feito para o JBoss.

Então nossos esforços serão basicamente mudar configurações do JBoss para o Tomcat e passar para o Seam o tratamento de features enterprise. As instruções são para o seguinte ambiente:

  • Eclipse 3.3.2 com JBoss Tools 2.1.1.GA
  • JBoss Seam 2.0.3.CR1
  • Apache Tomcat 6.0.16

Vamos lá:

  1. Já que estamos rodando num container web não temos o controle transacional provido pelo AS, então devemos passá-lo para o Seam.
  2. No persistence.xml alteramos o transaction-type da persistence-unit para RESOURCE_LOCAL e removemos a property hibernate.transaction.manager_lookup_class. Vamos mudar também a linha do data source, para utilizar ENC. Ela deve refletir:

    <non-jta-data-source>java:comp/env/jdbc/meuDatasource</non-jta-data-source>

    Note que aqui perdemos a possibilidade de transações distribuídas.

  3. Vamos definir agora no components.xml que o Seam será responsável pelo controle transcional. Adicionamos a seguinte linha:
  4. <transaction:entity-transaction entity-manager="#{entityManager}"/>

    Onde #{entityManager} é o nome da managed-persistence-context, que é o persistence context que será usado pelo Seam nas conversações. A definição do namespace:

    xmlns:transaction="http://jboss.com/products/seam/transaction"
    xsi:schemaLocation="http://jboss.com/products/seam/transaction http://jboss.com/products/seam/transaction-2.0.xsd"
  5. Para finalizarmos com essa parte de persistência falta apenas criar o próprio datasource. Quem usa o Sysdeo deve ir nas propriedades do Tomcat Project fazer isso, mas quem usa o WTP (usem!) não tem essa opção. Ao invés disso podemos usar o esquema de deploy de contexto do Tomcat. Crie um arquivo context.xml em seu WEB-INF/META-INF contendo seu data source. No meu caso:
  6. <?xml version="1.0" encoding="UTF-8"?>
    <context>
    <resource name="jdbc/meuDatasource" type="javax.sql.DataSource" driverClassName="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:meuBD" username="sa" password="" auth="Container" maxActive="20" maxIdle="5" maxWait="10000"/>
    </context>
  7. Por último temos que adicionar as seguintes bibliotecas que não vêm no Tomcat:
  8. persistence-api.jar
    hibernate.jar
    hibernate-entitymanager.jar
    hibernate-validator.jar
    hibernate-annotations.jar
    dom4j.jar
    jta.jar
    hibernate-commons-annotations.jar
    cglib-nodep.jar
    antlr.jar
    jboss-common-core.jar

    jsf-api.jar
    jsf-impl.jar

    commons-logging-1.1.1.jar
    commons-collections-3.2.1.jar
    javassist.jar

    A maioria delas pode ser achada na pasta lib do Seam. No meu caso criei uma User Libraries e as marquei como dependência para a Web Library, assim organizo meus jars e torno mais fácil a adição desses frameworks em projetos futuros.

Assumi que se sabe somo criar um projeto Seam. Deixei a idéia de um tutorial básico de lado, quero ainda falar do uso do JBoss Tools para geração de código e um pouco da integração com o Drools e com o jBPM (muito interessante!!).

Dêem o feedback sobre o que querem ler! Que se houver muita manifestação de interesse faço um post, até se for o caso, sobre o gorado tutorial ou o passo-a-passo para a criação de um projeto Seam.

referência: Edem Morny’s Tech Blog

Rapidinha: pull vs push MVC

June 24th, 2008

O padrão push é o de mais tradição, nele os dados são previamente carregados e disponibilizados para a camada de apresentação. Na prática: por exemplo o Struts com sua Action carregando os dados no request para serem usados na JSP.

No padrão pull a camada de apresentação é quem faz as chamadas aos componentes que irão lhes retornar os dados. Na prática: pro exemplo a página JSF invocando um getter no backing bean.

Resultado: no padrão do Struts muitas vezes os dados são gerados de forma que não podem ser facilmente reutilizados. Por outro lado JSF torna a reutilizacão muito mais clara e direta, através de componentes, no melhor estilo OO. Pessoalmente vejo a relação página-objetos muito mais intuitiva do que página-ação.

Treinamento Seam

June 10th, 2008

Começei essa semana no treinamento JB170 JBoss: SEAM Essentials, da Red Hat. Ele está sendo ministrado pelo João Paulo na Mirante. Nunca havia mexido com Seam embora já tivesse lido bastante sobre em artigos. É uma palavrinha que vem aparecendo cada vez mais no dia-a-dia de quem mexe com tecnologia e muitos livros vêm sendo lançados.

Tive a primeira aula ontem e me pareceu ter idéias muito interessantes. Os não tão atuais esforços de padronizar a idéia do Seam sobre a JSR 299 (Web Beans) deverão dar um maior impulso e maior adesão ao Seam. Vejo vários indícios de um futuro próspero para esse framework.

Acabado o curso pretendo dar um overview sobre o Seam e quem sabe fazer um tutorial ao longo de vários posts. Aguardem!

Sun Certified Web Component Developer for the Java Platform, Enterprise Edition 5 (CX-310-083)

June 2nd, 2008

Hoje foi a vez da prova de Web Component Developer. Passei com 76%, bem apertado mesmo. Estudei unica e exclusivamente SCWCD Exam Study Kit, único livro na biblioteca da empresa sobre o assunto. Faltando apenas 10 minutos para o início do meu exame meu nome ainda não havia aparecido no sistema e a recepcionista teve que contactar o pessoal do Prometric. Tudo certo, fui ao exame.

Aquelas típicas perguntas pré-teste pareceram maiores e foram um tanto chatas de se responder. No mais o tempo para essa prova, assim como a de SCJP, também foi muito grande. Sai da sala com ainda 1:20 para o término da prova.

A prova começou fácil e não assustou muito. Algumas questões bem de decorar, eu já sabia que iam cair. E muita coisa sobre tags, inclusive JSTL. Não esperava que fosse ser cobrado do jeito que foi. Tive que fazer uma força para lembrar dos velhos tempos em que usava Struts. Gostaria de ter estudado com mais afinco, estava imaginando que ela fosse ser muito tranquila de se fazer com o que uso no dia-a-dia.

Quick one

May 26th, 2008

This one is for all of you who (like me) keeps wasting time using commands such as find, jar and grep each time you get a classpath error:

#!/bin/bash
if [ "$1" = "" ]; then
	echo "Usage: jarfind REGEXP";
	exit;
fi
 
for d in `find . -name '*.jar'` ; do
	FILES=`unzip -l $d | cut -c 29- | egrep ''$1''`;
 
	if [ "$FILES" != "" ]; then
		echo "$d";
 
		for f in $FILES ; do
			echo " - $f"
		done
	fi
done

I’ve chose to use unzip instead of jar since it’s far more commonly seem. Move it to /usr/local/bin/jarfind (well, that’s a little personal) and chmod it to +x.

I works searching all jars under the current directory for a regular expression, most commonly a simple class name. It returns the jar’s names and all corresponding class matches.

I’m not a bash programmer, so it may not look that pretty to experienced bash programmers, but it looks beautiful to me, as it saves me a lot of time =). Feel free to make any comments.

EDIT:

first known bug: doesn’t escape special characters in paths =/

Sun Certified Programmer for the Java Platform, Standard Edition 6 (CX-310-065)

April 6th, 2008

Fiz quinta passada a prova de SCJP 6. Foram 72 questões e passei com 86%. Como já tinha experiência com Java, deixei para estudar apenas quando terminasse a prova da IBM.

Como fonte de estudo usei o livro da Katherine Sierra, já consagrado entre todos os test takers do SCJP. Usei também o Sun Academic Initiative do qual fiz apenas os simulados, mas me pareceu ter um bom material para estudo. Dei umas clicadas também no Scjp Faq do JavaRanch, que tem um material talvez até extenso demais.

A prova foi tranquila e deu para acabar faltando ainda 1:30 de prova. Tive um susto durante a prova: o programa deu um erro, travou e fechou. Nisso eu estava no meio da revisão da prova, agora imaginem a minha reação… Depois do técnico reiniciar o computador (é Windows), o programa da Prometric me mostrou a prova de onde havia parado. Foi um alívio.

Acostumado com as interfaces dos mocks, tive uma agradável surpresa ao ver a interface do programa da Prometric. Os códigos maiores eram postos em janelas a parte de forma que dava para organizar a melhor a vizualização, os drag and drops, também foram bem feitos e a única coisa de que não gostei é que não se podia revisar as questões de drag and drop sem que se perdesse as respostas dadas.

Java portável?

February 11th, 2008

Há pouco tempo enviei um email com recomendações para o pessoal de desenvolvimento da minha empresa, transcrevi muito do email aqui e alterei algumas coisa:

Tenho visto muito problema para fazer deploy de aplicações no que diz respeito à portabilidade das aplicações. Em minha empresa desenvolvemos em Windows mas no cliente usamos servidores Linux. Aqui vão algumas recomendações para evitar esses problemas:

  • Evitem sempre que possível classes do pacote com.sun.*, nem sempre o cliente usa a JVM da sun (no meu caso era mais simples copiar o rt.jar da JVM da Sun para o lib/ext, mas é um tanto gambiarra.. além do mais esse jar tem mais de 40mb);
  • Quando chamarem comandos externos no Ant chamem pelo nome em minúsculo, há diferenças de case senssitiveness entre OS’s, e os comandos em geral são em minúsculo em OS’s Unix-like. E antes de fazer qualquer dessas chamadas, procurem se já não existe uma task para isso, o script fica muito mais limpo e utiliza-se a portabilidade do Java corretamente;
  • Tomem cuidado também com o nome que vocês dão às pastas e arquivos. Estabeleçam um nome e sigam ele, não misturem “InfraEstrutura.txt” com “infraestrutura.txt”;
  • Quando forem compilar qualquer coisa para distribuição usem o parâmetro encoding do javac, iso-8859-1 no caso de se usar Windows e os arquivos estarem salvos no encoding padrão. Na verdade, creio que o mais correto seria desenvolver em utf-8, mas…
  • Evitem caminhos absolutos! Nem todo OS tem c:\!

Mais alguns toques para scripts Ant de distribuição: habilitem o nowarn, os warnings dão impressão de má qualidade e sujam o log; tentem fazer um script que possa ser robotizado (sem nenhum input), muitas vezes é interessante criar cron jobs para ele.