A fim de fazer testes com várias configurações diferentes e gerar um relatório com dados precisos, escrevi um script que executa o init script do JBoss, espera ele inicializar completamente, grava o tempo de inicialização e mata o processo. Faz isso 50 vezes.

Estou postando ele aqui na esperança de ser útil para mais alguém. Ele é bastante auto-explicativo:

#!/bin/bash
# Notes: all Java processes are going to the KILLED and
# previous probe.log ERASED!
 
JBOSS_LOG_FILE="/opt/jboss/server/default/log/server.log"
REPEAT=50
 
START_STRING="Started in"
RESULT_FILE="/root/probe.log-`date +%F`"
> $RESULT_FILE
 
for i in $(seq 1 $REPEAT); do
	# clean
	killall -9 java
	> $JBOSS_LOG_FILE
 
	# init and wait
	sh /etc/init.d/jboss start
	while [ "x$( grep "$START_STRING" $JBOSS_LOG_FILE )" == "x" ]; do
		sleep 1
	done
 
	# log
	cat $JBOSS_LOG_FILE | grep "$START_STRING" >> $RESULT_FILE
done
 
echo "Done"

De volta do Devoxx! O evento foi muito bom. De longe o maior, mais alto nível, melhor organizado evento que já fui.

Minha palestra aconteceu na quarta e qual foi minha surpresa ao ver o Pete Muir (Seam/Weld/Arquillian), Dan Allen (Seam/Weld/Arquillian) e Aslak Knutsen (Arquillian lead) sentados na primeira fileira!

O mais legal foi ter conversado com eles e eles terem me mostrado que a proposta que apresentei já está no road map do Arquillian. Legal!

O evento foi uma ótima oportunidade para fazer networking. Além do convite para um brainstorm regado a cerveja belga do time do Arquillian, encontrei os brazucas Yara e o Vinícus Senger lá também.

Outra pessoa com quem estava querendo trocar umas idéias é o Mathieu Ancelin, criador do weld-osgi, idéia que eu há muito queria implementar e ele fez eximiamente.

Deve estar saindo nos proximos dias um artigo que escrevi para a InfoQ BR sobre a cobertura do Devoxx. Quando sair post o link aqui. Também disponibilizei os slides da palestra no Slideshare.

FirefoxProfile profile = new FirefoxProfile();
// here's the important part
profile.setPreference("permissions.default.image", 2);
 
WebDriver driver = new FirefoxDriver(profile);
selenium = new WebDriverBackedSelenium(driver, "http://rafaelliu.net");

Com isso o Firefox não irá requisitar, baixar e renderizar imagens. A diferença varia de acordo a quantidade de imagens na página e hits no cache. Executei um teste no http://g1.globo.com/ com 10 iterações, o que resultou nos seguintes tempos (em milissegundos):

NormalSeleniumTest - 39021ms
TweakedSeleniumTest - 29072ms

Hope that helps!

Referência: http://kb.mozillazine.org/Permissions.default.image

1. Adicionando uma Category ao $JBOSS_CONF/conf/jboss-log4j.xml pegando todos o package da aplicação e usando um Appender específico. Por exemplo:

   <category name="net.rafaelliu">
     <priority value="INFO" />
     <appender-ref ref="BLOG_LOG"/>
   </category>

Embora seja a solução mais fácil, a separação não está perfeita. Como estamos separando por pacotes, um erro no Hibernate por exemplo, ainda vai ser escrito no server.log, mesmo tendo sido lançado pela aplicação.

2. Usando Filters é possível criar um TCLFilter para pegar apenas logs de determinada aplicação. Basta criar um Appender específico:

   <appender name="BLOG_LOG" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.log.dir}/blog.log"/>
      <param name="Append" value="true"/>
      <param name="DatePattern" value="'.'yyyy-MM-dd"/>
      <layout class="org.apache.log4j.PatternLayout">
         <param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
      </layout>
 
      <!-- filter -->
      <filter class="org.jboss.logging.filter.TCLFilter">
         <param name="AcceptOnMatch" value="true"/>
         <param name="DeployURL" value="blog.war"/>
      </filter>    
      <filter class="org.apache.log4j.varia.DenyAllFilter"></filter>
   </appender>

O problema aqui é que, embora o log seja gravado separadamente (inclusive de pacotes do Hibernate, por exemplo), ele será gravado duas vezes: uma vez no blog.log que definimos e uma vez no server.log do JBoss. Isso resulta em mais IO e mais espaço em disco.

3. Empacotando um log4j na própria aplicação, em WEB-INF/lib, é possível inverter o classloader e fazer com que as configurações do log4j valham apenas para sua aplicação:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
	<class-loading java2ClassLoadingCompliance="false">
		<loader-repository>
			net.rafaelliu:loader=blog.war
			<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
		</loader-repository>
	</class-loading>
</jboss-web>

Feito isso, é preciso criar o log4j.properties (ou xml) normalmente:

log4j.rootLogger=${jboss.server.log.threshold}, fileout
 
log4j.appender.fileout=org.apache.log4j.DailyRollingFileAppender
log4j.appender.fileout.File=${jboss.server.log.dir}/blog.log
log4j.appender.fileout.Append=true
log4j.appender.fileout.DatePattern='.'yyyy-MM-dd
log4j.appender.fileout.layout=org.apache.log4j.PatternLayout
log4j.appender.fileout.layout.ConversionPattern=%d %-5p [%c] (%t) %m%n

O log4j faz parse de system properties, que podem ser usadas no arquivo de configuração. Uma observação importante é que não é possível usar classes do JBoss aqui! Isso causaria ClassCastExceptions. Algumas dicas:

• No JBoss 5, use o jboss.server.log.dir e o jboss.server.log.threshold. Isso facilitará o deploy da sua aplicação em outros ambientes;
• Use o mesmo Appender do jboss-log4j (provavelmente uma classe da JBoss estará lá, veja o equivalente da Apache). Isso deixa os logs do JBoss e das aplicações sincronizados, facilitando o correlacionamento de erros;

O problema dessa abordagem é que perdemos o “hot deploy” do jboss-log4j.xml, que nos permite alterar o nível de log sem indisponibilidade.

Referências:
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html
http://viragine.blogspot.com/2009/02/separando-o-log-do-jboss-as-por.html
http://community.jboss.org/wiki/SeparatingApplicationLogs

A edição Goiânia do TDC vai acontecer dias 29 e 30, e de novo estarei lá palestrando.

Sábado, dia 29/10, às 17:40 estarei falando sobre o Weld/CDI. Será uma palestra introdutória onde quero mostrar alguns recursos que temos e aplicações interessantes deles. Será uma versão mais básica da palestra que farei no Devoxx, e será focada em testes.

No domingo às 14:10 foi mostrar o Drools, a apresentação será similar à do TDC São Paulo, mas vou tentar me organizar melhor para mostrar todas as demos que tinha planejado mostrar Apareçam, prometo que vai ser interessante!

Em Novembro estarei na Bélgica para o Devoxx, que será uma semana inteira dedicada a tecnologia com representantes da Red Hat, Oracle, Adobe, Google, HP, IBM, SrpingSource e outros.

Lá vou fazer uma rápida palestra na quinta, dia 17/11, às 13:15. Vou falar como TDD combina com CDI: quais são os problemas enfrentados e quais alternativas temos. Terá um pouco de Weld, portable extensions e Arquillian. Aos brazucas que estiverem por lá, vamos combinar uma cerveja depois!

Foi muito bom! Um dia inteiro com geeks das mais diversas áreas num ambiente de troca de conhecimento incrível. As fotos estão no Picasa.

O local do evento ficou apertado para o tanto de gente que deu. Em algumas apresentações as salas ficaram abarrotadas, como a do @brunorst e @claudio4j falando de Tuning de JBoss e a do @vtcorrea e @g_luszczynski falando de Alta Disponibilidade. Ambas as palestras muito bem criticadas e ambas não pude ver..

O @salaboy abriu o evento com um keynote sobre jBPM5 seguido do @jedgarsilva, com toda sua manha de fazer apresentações, falando sobre Cloud. O @porcelli e o Pedro Igor falaram sobre noSQL e data grids e se complementaram bem o primeiro dando um banho (muito bem dado) de conceitos e o segundo falando de produto mesmo, o Infinispan. Para mim foram as apresentações mais interessantes porque nunca tinha ido atrás desses assuntos, que já estão há um bom tempo ai como buzzwords.

Uma apresentação que eu queria muito ter visto e perdi foi a do @jpviragine falando sobre Federação de Dados com o Teiid. No horário da apresentação dele eu estava na outra sala falando sobre JBoss Portlet Bridge. Uma pena, ainda mais vendo a boa repercussão que teve =/

Teve também Weld e Seam com o @rimolive e a @hannelita, que cobriram muito bem o assunto. O @rafabene e o @osmanlira mandaram muito bem na apresentação de Drools. O @rafaeltuelho falou sobre RHQ, com uma demo que pelo que ouvi foi massa. E restou à Flávia Rainone fechar o evento falando sobre JBoss7.

O evento foi nota 10, mesmo sendo apenas a primeira edição em Brasília. Fiquei muito feliz de ter podido palestrar nele porque o público estava muito interessado e não tem nada melhor do que ver gente interessada perguntando na sua palestra =)

Aos que não foram, recomendo não perderem a chance de se inscrever para a edição de 2012 já já deve tá vindo ai.

Cheers!

Se você quer utilizar o GateIn com Tomcat é um pouco mais complicado, mas nada preciso adicionar a instalação do Tomcat do GateIn normalmente fazer algumas alterações:

1. Mudar no “Server Location” para “Use Tomcat installation (takes control of Tomcat installation)”

2. No  ”Launch Configuration” configurar o “Working directory” com o $TOMCAT_HOME

3. Ainda no  ”Launch Configuration” adicionar os parâmetros:

-Djava.security.auth.login.config=../conf/jaas.conf

-Dexo.conf.dir.name=gatein/conf

4. Provavelmente será também preciso alterar limites de memória da JVM e timeouts de subida/descida do WTP.

Para desenvolver no GateIn, tanto no JBoss quanto no Tomcat, pode ser interessante adicionar o parâmetro -Dexo.product.developing=true, que desabilita vários caches e desabilita o merge/compressão de CSS e JS.

<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:jaxws="http://cxf.apache.org/jaxws"
   xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
 
   <import resource="classpath:META-INF/cxf/cxf.xml" />
   <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
   <import resource="classpath:META-INF/cxf/cxf-extension-http-jetty.xml" />
 
   <jaxws:endpoint name="testService"
      implementor="net.rafaelliu.services.TestImpl"
      address="http://localhost:9000/test">
 
      <!-- Enable WS-Addressing -->
       <jaxws:inInterceptors>
         <!-- Enable WS-Security -->
         <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
            <constructor-arg>
               <map>
                  <entry key="action" value="UsernameToken" />
                  <entry key="passwordType" value="PasswordText" />
                  <entry key="passwordCallbackClass" value="net.rafaelliu.callbacks.ServerPasswordCallback"/>
               </map>
            </constructor-arg>
         </bean>
       </jaxws:inInterceptors>
   </jaxws:endpoint>
 
 
   <jaxws:client name="testClient"
      address="http://localhost:9000/test"
      serviceClass="net.rafaelliu.services.Test">
 
      <jaxws:outInterceptors>
         <bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
            <constructor-arg>
               <map>
                  <entry key="action" value="UsernameToken" />
                  <entry key="passwordType" value="PasswordText" />
                  <entry key="user" value="rafaelliu" />
                  <entry key="passwordCallbackClass" value="net.rafaelliu.callbacks.ClientPasswordCallback" />
               </map>
            </constructor-arg>
         </bean>
      </jaxws:outInterceptors>
 
   </jaxws:client>
 
</beans>

É possível ver que no client definimos um outInterceptor que irá adicionar os headers com o token Username (um dos possíveis tokens como havia dito no post anterior, poderia ser Kerberos, SAML ou algum certificado) e no serviço definimos um inInterceptor que irá vazer a validação do envelope SOAP que chegar, verificando no header as credenciais.

Ambos os interceptors utilizam Callbacks para recuperar a senha a partir do nome do usuário. No client o callback será utilizado para setar a senha e no serviço será utilizado para recuperar a senha a partir do nome do usuário presente no header, que será comparada com a senha que veio junto do header.

A implementação dos Callbacks é Java puro, provavelmente utilizaria um DB ou LDAP, e é bastante simples:

public class ClientPasswordCallback implements CallbackHandler  {
 
   @Override
   public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
        WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
 
        if (pc.getIdentifier().equals("rafaelliu")) {
          pc.setPassword("abc123");
        }
   }
 
}

E para o serviço:

public class ServerPasswordCallback implements CallbackHandler  {
 
   @Override
   public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
        WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
 
        String password = null;
        if (pc.getIdentifier().equals("rafaelliu")) {
           password = "abc123";
        }
        if (password == null || !password.equals(pc.getPassword())) {
           throw new IOException("wrong password");
        }
   }
 
}

Uma nota importante é que o callback do serviço é responsável por lançar uma exceção caso o a senha do usuário não seja validade. Isso se deve à implementação do WSS4J, framework também da ASF que o CXF usa para WS-Security. Não testei, mas parece que na versão 2.4 do CXF, ou mais precisamente no WSS4J 1.6, esse comportamento mudou e o callback realmente ficou só um callback.

Bonito hein?

Reclamam: maven baixa toda a internet

Acho que quem reclama não entende muito como funciona o sistema de dependências do maven. O maven não faz (muita) mágica. O dono do artefato tem que definir as dependências do artefato.

Ou seja, de duas uma: ou o maven está baixando a internet porque os mantenedores doas artefatos foram relapsos ou realmente todas aquelas dependências eram necessárias.

Se foi preguiça do desenvolvedor, não é culpa do maven. Todos conhecemos sistemas de empacotamento (port, portage, agt, yum) e sabemos que tem muito mantenedor preguiçoso que, em vez de deixar as dependências enxutas, põe tudo como dependência para poupar dor de cabeça. Onde está o problema do maven aqui? Maven é uma ferramenta, ele faz o que for mandado.

Se é porque realmente existiam muitas dependências, ai não tem o que falar mesmo. Provavelmente esse pessoal que reclama nunca entrou site por site, procurando os binários, lendo documentação de que versão é compatível com que versão. Só de me poupar esse trabalho, mesmo com pom’s totalmente bagunçados, que baixam o repositório inteiro, para mim vale a pena usar maven. Dica: você não precisa ficar olhando o terminal esperando tudo ser baixado.

E ele baixa cada pacote uma única vez, é muito choro por pouca coisa. Além do disso, coisas que parar mim salvam muito tempo e o pessoal não pensa..

Não pensam: baixa dependências (transitivas!)

Agora com o Ivy isso já não é tão extraordinário, mas o Ivy foi provocado pelo Maven. Aliás, o Ivy usa os repositórios do Maven! Nunca usei o Ivy, mas para mim isso significa que ele também irá baixar toda a internet.

Não pensam: analisar source de pacotes

Já teve que decompilar classes com o jad (ou qualquer outra ferramenta) para debugar código? Quem já fez isso percebeu que é um pé no saco ter que decompilar todas as classes que formam a stack (e provavelmente mais) e ainda ter os números de linha todos bagunçados impedindo de usar o source na IDE para setar break points. Ou isso ou você procurava o source para baixar (de novo, procurando site em site) quando não tinha que fazer checkout de SCM e tendo que achar a tag certinha!

Não pensam: tooling

Já usou o m2eclipse (o antigo, antes da Sonar doar pra Eclipse)? Quando trabalhava em fábrica lembro o terror e pânico quando alguém commitava o .project, era ficar ajustando classpath um bom tempo. E tem algo mais porco que versionar JARs? Busca JARs, adiciona projetos dependentes ao classpath sem precisar dar build, mostra a árvore de dependência, o pom efetivo. Ele tem bugs sim, mas nem de longe vale a pena deixar de usá-lo por causa disso.

Para os que reclamam: Everythings Amazing & Nobodys Happy

Tente parar de usá-lo para ver o quanto vão dar valor a ele.

Com o intuito de promover e disseminar as tecnologias open source JBoss, foi criado o evento JBossInBossa.

O JBossInBossa é um evento de tecnologia para profissionais ávidos por novidades tecnológicas open source para o desenvolvimento de soluções corporativas.

Grandes nomes como Alexandre Porcelli, Claudio Miranda e Paulo Gerônimo estarão lá. Vou dividir palco com eles pra falar sobre Portal, mais especificamente JBoss Portlet Bridge e GateIn, na Sala 01 às 16:30. Apareçam lá!

Site: http://www.jbossinbossa.com.br/2011/index.html