mnemetica

Relatório de Atividades, 30/10/2005

Tirei o dia de hoje atualizando um projeto. Em particular, alguns frameworks que compôem as dependências.

Comentários notáveis:

==== MINA ====

A parte de rede é baseada em um framework chamado [[http://directory.apache.org/subprojects/network/ MINA]] (Multipurpose Infrastructure for Network Applications), que por sua vez é um subprojeto do [[http://directory.apache.org/ Apache Directory Server]] (um servidor de protocolo, incluindo DHCP, DNS, NTP, e Kerberos. MINA é baseado em um framework anterior chamado [[http://gleamynode.net/dev/tl-netty2/docs/ Netty2]].

Qual o ponto de usar-se MINA? Bem, o principal, na minha opinião, é a facilidade de me oferecer várias features (SSL, NIO, Sockets In-VM, multiplos protocolos) sem ter que fundir meus neurônios. A idéia central é que você sobreescreva métodos em uma classe ([[http://directory.apache.org/subprojects/network/apidocs/org/apache/mina/common/IoHandler.html IoHandler]]),
representando as operações primitivas de um protocolo. Simples, não?

A versão atual é a 0.9.0. Atualizar me deu alguns problemas, em particular pela versã0 0.9 reescrever a interface acima. Após algum sofrimento, o código compilou.

==== SLF4J ====

Infelizmente, a versão nova do mina introduziu uma dependência que eu apenas havia ouvido falar, mas que nunca a usara: [[http://www.slf4j.org/ SLF4J]]. É uma espécie de universo alternativo: SLF4J em si é uma espécie de alternativa ao [[http://jakarta.apache.org/commons/logging/ commons-logging]], mas sem [[http://www.qos.ch/logging/ alguns problemas]] citados pelo autor (que ocorre ser o autor do [[http://logging.apache.org/log4j/ log4j]]). Ou, agora, [[http://www.slf4j.org/nlog4j/ nlog4j]].

Algumas alterações no fonte foram necessárias. Por exemplo, uma classe que utilize commons-logging:

%%(java)
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class TesteLog {
private static final Log log = LogFactory.getLog(TesteLog.class);

public static void main(String[] args) {
log.info(“Inicializando.”);

try {
operacao();
} catch (Throwable t) {
log.warn(“Erro durante execucao: “, t);
}
}
}
%%

Vira:

%%(java)
import org.slf4j.LoggerFactory;
import org.slf4j.Logger;

public class TesteLog {
private static final Logger logger = LoggerFactory.getLogger(TesteLog.class);

public static void main(String[] args) {
logger.info(“Inicializando.”);

try {
operacao();
} catch (Throwable t) {
logger.warn(“Erro durante execucao: “, t);
}
}
}
%%

Isto não foi suficiente, pois o [[http://www.springframework.org/ Spring]] depende do commons logging. Mas pra isso, há uma versão da commons-logging que apenas redireciona para o slf4j.

A esta altura, puto de ter alterado tudo, resignei-me… A tendência, a longo prazo, é a adoção do slf4j, por um motivo simples: é feito pra ser modular, permitindo diferentes frameworks coexistindo sem problemas no classpath. Isto, por exemplo, é um dos pontos fortes do ([[http://jakarta.apache.org/hivemind/ Jakarta Hivemind]] sobre o Spring.

O que falta? Bem, preciso exportar uma funcionalidade via RMI. Mantenham ligados…