Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Seam 3 mudou bastante os princípios por trás dos frameworks da família Seam. Até o Seam 2, o núcleo do framework era um módulo responsável pela injeção de dependências. A plataforma era intimamente integrada – ou acoplada, dependendo do ponto de vista. Entretanto, Seam 3 abandonou o núcleo anterior em favor do CDI, a nova especificação de injeção de dependências da Java EE 6, e as demais partes da plataforma foram substituídas por módulos totalmente desacoplados.

Nos primeiros artigos desta série, vimos como CDI implementa injeção de dependências, gerenciamento de contextos, eventos, interceptadores e decoradores. No artigo anterior, vimos dois dos módulos de Seam 3 – Solder, que contém inúmeras ferramentas genéricas, e Catch, para tratamento centralizado de exceções. Entretanto, vimos também que Seam estava passando por mudanças e seu futuro ainda estava indefinido.

Recentemente, após receber feedback da comunidade, o time de desenvolvedores do JBoss Seam anunciou uma grande mudança: vários módulos de Seam 3 seriam alocados em outros projetos. Dos diversos módulos originais do framework, porém, quatro ainda seriam mantidos pela equipe de Seam: Solder, Catch, Config e Servlet. A partir da versão 3.1, estes módulos estarão fundidos em um só, o novo Seam Solder. Como já estudamos Solder (como definido na versão 3.0) e Catch no artigo anterior, veremos, neste artigo, o módulo Config.

Mudanças ainda mais drásticas ocorrerão com o Seam 3. A mais importante é que o novo Seam Solder será integrado a outros complementos portáveis para CDI (como Apache CODI e CDISource), em um grande projeto, sob a égide da Apache Foundation. Estas mudanças serão mais bem explicadas no próximo artigo da série.

Seam Config

O uso de XML em CDI é bastante limitado. Exceto pelos arquivos exigidos por aplicações web Java (como o web.xml), uma aplicação CDI precisa apenas do beans.xml, que pode inclusive não ter conteúdo. Além disso, quando se configura a aplicação através do beans.xml, apenas aspectos de implantação são definidos – a lógica de negócio é toda expressada em Java. Esta abordagem contrasta com a maioria dos frameworks em Java, que utilizam XML para as mais diversas tarefas: desde rotear requisições para actions, até injetar dependências. Este é um dos aspectos mais elogiados de CDI, pois configurações em XML são difíceis de depurar, pouco legíveis e fracamente tipadas.

Por outro lado, configurações em XML são mais flexíveis e fáceis de customizar. É possível alterar vários aspectos de uma aplicação sem precisar recompilá-la. Componentes diferentes podem ser usados em ambientes de implantação diferentes apenas trocando arquivos de configuração. Com Weld, podemos utilizar beans anotados com @Alternative para obter resultado semelhante, e Solder oferece algumas funcionalidades úteis nesta mesma linha (como a anotação @DefaultBean). Entretanto, estas ferramentas focam-se mais em definir beans com comportamentos variados, ao invés de definir parâmetros em beans com igual comportamento. Na prática, porém, é bastante usual querer mudar apenas um parâmetro no comportamento de um bean. Por exemplo, queremos que nosso entity manager se conecte a um banco de dados em homologação e a outro em produção, mas não queremos usar dois tipos de entity managers. Nestes cenários, as ferramentas de Weld e Solder podem ser desnecessariamente complicadas."