Bruno Pereira

Continuando o tema do meu artigo anterior, agora quero falar sobre a importância do open source profissional.

Na última quinta-feira eu fui na palestra do Bruno Borges no RioJUG, sobre Apache Camel. A palestra em si foi bem legal, pois eu já conhecia um pouco do Apache Camel e pude ver algumas coisas a mais. Mas o ponto específico que eu quero abordar é um comentário que o Bruno fez, que diverge da minha postura em relação a open source.

Ele comentou que tenta sempre utilizar produtos Apache, evitando produtos open source que tenham vínculo com alguma empresa, como JBoss, SpringSource, entre outras. Não me recordo do motivo exato, mas a razão principal que ele explicou é o fato da Apache Software Foundation ser uma fundação composta de pessoas, em vez de ser uma empresa com fins comerciais.

Eu tenho uma postura diferente da dele em relação a open source. Eu gosto muito e tenho um respeito enorme pela fundação Apache. Já usei inúmeros produtos Apache e certamente continuarei usando por muito tempo. Entretanto, já usei vários produtos JBoss e vários componentes do Spring, e acho muito importante e saudável a existência dessas empresas.

A história do movimento open source tem vários elementos “românticos” e “filosóficos”, e essa característica ainda é muito presente em várias comunidades hoje em dia. Entretanto, com o crescimento do Linux, Java, Python, Ruby e outras tecnologias, existe hoje um mercado enorme de trabalho e negócios em torno do software livre.

O surgimento desse mercado naturalmente trouxe a participação de muitas empresas que vivem de software livre atualmente. Sei que há pessoas que enxergam open source e capitalismo como coisas opostas, mas na minha opinião essa visão é míope. Open source é um modelo de desenvolvimento de software e oferta de produtos e serviços. A busca do lucro é o que move nossas empresas, e isso não é diferente para quem atua com software livre.

O surgimento das empresas profissionais open source foi importantíssimo para o amadurecimento das tecnologias e dos profissionais. Se o movimento open source continuasse restrito ao meio acadêmico, o nível de competição no mercado de software seria muito menor, e o avanço tecnológico teria sido bem mais lento.

Além disso, minha postura profissional é de tentar sempre entregar os melhores resultados para os clientes e para a empresa em que trabalho. Em algumas situações pode ser mais adequado usar open source, em outras pode ser necessário usar software proprietário. Temos que nos adequar às necessidades dos clientes, em vez de esperar que eles se adeqüem às nossas preferências.

No meu ponto de vista, empresas como JBoss e SpringSource contribuíram e contribuem muito no processo de profissionalização do software livre. A existência delas criou um mercado fortíssimo em torno do software livre, e eu só tenho a agradecer por isso.

Um amigo meu me pediu umas dicas de estudo para se tornar um desenvolvedor web produtivo e com boa empregabilidade. O ideal para ele é ter como base a plataforma Java, mas sem ficar restrito a Java. Talvez isso possa ser útil para outras pessoas também, então colocarei as dicas a seguir.

Framework web Java

Considerando o critério empregabilidade, é fundamental conhecer razoavelmente Struts 1.x. Eu creio que poucos projetos hoje em dia sejam iniciados usando o Struts 1.x, mas a quantidade de aplicações em produção com esse framework é enorme, e durante um bom tempo essa realidade ainda se manterá.

Depois do Struts 1.x, nenhum outro framework web Java conseguiu adoção semelhante, então é difícil recomendar uma opção mais moderna que garanta alguma coisa. É provável que a melhor opção “moderna” em termos de empregabilidade seja Java Server Faces, mas não me sinto bem em recomendar que ninguém estude JSF. Se alguém quer seguir na linha do JSF, eu recomendaria o JBoss Seam, do qual ouvi boas avaliações, mas nunca usei.

Dos frameworks web Java mais recentes, o meu preferido é o Spring MVC 2.5.x. O importante da versão 2.5 em diante é que os controllers suportam anotações para configuração, em vez dos XMLs monstros que eram a opção anterior. A maioria dos frameworks web está seguindo numa abordagem RESTful de arquitetura, o que me agrada também. O Spring MVC é um dos que está fazendo isso, e com uma abordagem legal.

Além disso, todos os componentes do Spring acabam te “seduzindo” a usar outros componentes dele, pela conveniência e pela qualidade dos mesmos. Então se você usar o Spring MVC, é muito provável que use a injeção de dependências, o controle transacional, talvez o web flow, entre outras coisas.

Frameworks web da “nova geração”

Qualquer desenvolvedor web hoje em dia TEM OBRIGAÇÃO de olhar pelo menos um entre Django, Grails e Ruby on Rails. O ideal mesmo é avaliar os três e ter um deles como opção principal. Eu já conheço legal o Grails e estou evoluindo rápido com o Django. Em algum momento esse ano eu dedicarei um bom tempo avaliando e fazendo algo relevante com Ruby on Rails também.

Pode parecer que leva um tempo enorme para conhecer os 3, mas isso não é verdade. Os 3 são extremamente produtivos e têm muitas características semelhantes. Quando você começa a utilizar um deles já tendo experiência com outro, a curva de aprendizado fica muito rápida.

Um aspecto muito legal do aprendizado desses frameworks da “nova geração” é que você tem contato com outras formas de fazer software (para quem tem um background Java), outras comunidades, e várias idéias interessantes que te farão um programador melhor em qualquer linguagem ou plataforma. Se você ainda não conhece nenhum dos 3, não perca mais tempo e escolha um para começar. E de preferência conheça os outros em seguida também

HTML, CSS, Web Standards

Estamos em 2009. Embora ainda vejamos muitos sites bisonhos que só funcionam com o IE, se você é um desenvolvedor que se preza você precisa conhecer bem HTML, CSS e os web standards. Na verdade, fazer o site funcionar no IE 6 por exemplo é secundário. Você precisa aprender primeiro a gerar HTML e CSS válido de acordo com as normas da W3C, que garantem padrões de qualidade e interoperabilidade entre browsers. Leia de cabo a rabo todos os tutoriais referentes a essas coisas no W3Schools. É muito rápido estudar por lá, e é uma ótima referência depois.

Depois que você conhecer isso, um pouco de prática na escola norueguesa de software fará suas aplicações rodarem no IE 6 também

Javascript

Ainda há pessoas que escrevem javascript na unha, mas acho que elas são cada vez mais raras. Temos hoje uma oferta enorme de bibliotecas javascript para resolver todos os problemas comuns dos desenvolvedores web. Eu era um fiasco em javascript antes de conhecer o jQuery, mas há um bom tempo eu gosto MUITO de javascript, e minha produtividade no client-side melhorou absurdamente.

O jQuery tem uma abordagem que eu acho excepcional. Temos 3 aspectos claramente distintos para tratar em uma página web: Estrutura (HTML), Estilo/Visual (CSS) e Comportamento (Javascript). Se você fizer tudo direitinho e usar o jQuery, essas 3 coisas ficam totalmente desamarradas.

Você não precisará colocar nenhuma declaração de estilo na estrutura (leia-se: sem CSS inline). A definição do comportamento fica totalmente por fora da estrutura. A beleza do jQuery está em aplicar todo o comportamento da página de uma maneira não-intrusiva, e com uma abordagem muito limpa. Ah, e o javascript funcionará em todos os browsers sem você ter que tratar disso explicitamente. Um sonho, não é mesmo?

Há várias outras opções, e não estou defendendo a idéia de que se use apenas uma. Eu uso o jQuery para tudo que posso, e até hoje não precisei de outra biblioteca, mas vá em frente e experimente algumas opções até encontrar o que lhe atender melhor.

Plugins legais do Firefox

Firebug

Além do jQuery, outra descoberta que mudou minha opinião e gosto por client-side foi o Firebug. Ele ajuda MUUUUUITO na criação do HTML/CSS das páginas, pois você consegue inspecionar de forma fácil o conteúdo e o estilo, e aplicar mudanças imediatas sobre o que está vendo. Depois de acertar as coisas pelo Firebug, você simplesmente aplica as mudanças no HTML/CSS originais e continua implementando sua página. Além disso, ele te permite debugar javascript e analisar as requisições HTTP detalhadamente. Eu já o utilizo há pouco mais de 1 ano, e ele contribuiu muito para meu amadurecimento no client-side, e me dá muito mais produtividade.

Web Developer

Um companheiro freqüente do Firebug é o Web Developer. Ele te permite inspecionar detalhadamente uma porção de coisas na sua página, como informações de todas as imagens, todos os formulários, estilos, entre outras coisas. Além disso, permite a manipulação de cookies, valida HTML/CSS/Javascript, e tem muitas outras funcionalidades úteis. É indispensável para trabalhar com web, assim como o Firebug.

Screengrab

É muito comum termos que mostrar uma página para outras pessoas, e nem sempre elas têm acesso à nossa máquina. Para facilitar isso, podemos usar o Screengrab, que é semelhante a um Print Screen, mas salva o conteúdo completo da página como uma imagem. Isso é bem melhor do que o Print Screen, pois pega apenas a área útil da página (sem pegar barras do Firefox e barra de tarefas) e pega toda a área útil. As regiões da página que precisam ser “roladas” para visualização também são incluídas na imagem, o que é certamente o desejado.

NoScript

O NoScript é um plugin bem incômodo para uso em geral. Ele bloqueia a maioria dos javascripts e você precisa ficar liberando a execução de scripts toda hora. Quando não estou desenvolvendo eu sempre deixo ele desligado.

Entretanto, para desenvolver ele ajuda em algumas situações. Por exemplo, você pode precisar desabilitar alguns scripts específicos da sua página para testar alguma coisa, ou testar se a página funciona sem scripts. Ou então você pode ter uma situação como uma recente minha.

Eu tive que customizar um plugin do jQuery que faz algumas animações, e aí o HTML da página ficava mudando o tempo todo. Eu precisava customizar o HTML/CSS de vários “instantes” da animação, mas era impossível fazer isso com a animação rodando. Para resolver isso, eu usei o NoScript para interromper os scripts exatamente no trecho da animação que eu precisava mudar o HTML/CSS. Com isso, eu conseguia um HTML estático que eu podia mexer pelo Firebug, e consegui trabalhar tranqüilamente nas customizações que eu precisava fazer.

Conclusão

Deixei algumas opiniões e dicas sobre algumas coisas de desenvolvimento web, mas é óbvio que eu também tenho muita coisa a aprender. Se alguém discordar de alguma opinião minha ou quiser acrescentar sugestões, estejam convidados a participar :)  Além disso, se alguém tiver mais dicas de extensões do Firefox para desenvolvimento web, eu sempre estou interessado.

Pessoal, a Concrete está novamente contratando. Estamos trabalhando com projetos muito interessantes de portais atualmente, e neste processo seletivo estamos com 2 vagas, conforme abaixo.

Desenvolvedor Java (2 vagas)

Fundamental:

Experiência comprovada de pelo menos 4 anos de trabalho como programador/desenvolvedor de software.

Java EE 5 e 6.

JPA, Hibernate, Struts ou outro framework para web  em Java.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat  e Geronimo.

Conhecimento de banco de dados e mapeamento objeto-relacional (desejável).

Inglês para leitura e estudo de material técnico.

Comprometimento, concentração e auto-didatismo são valores extremamente importantes. Argumentação fundamentada .

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão ou Informática

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp

Conhecimento de plataforma Linux

Conhecimento em shellscripting para Unix/ Linux é bastante desejável.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Hoje o Sacha Labourey (CTO da JBoss) publicou um post interessante sobre as dificuldades que a Sun vem encontrando, em especial com seu modelo de negócios open source. Como eu já pensei um bocado sobre isso e conversei com algumas pessoas, vou deixar aqui algumas opiniões.

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

Ontem fui na palestra do Nico Steppat (da Caelum) sobre JBoss Seam no RioJUG. A palestra foi interessante, mas infelizmente não deu tempo pra ele mostrar tudo, e eu não vi muita coisa além do que eu já sabia.

Entretanto, um ponto destacado por ele me deixou ligado em um recurso interessante. Como ele mencionou, o Seam busca ajudar bastante em aplicações que precisam de estado, como um carrinho de compras. A proposta é de ser uma camada de ligação entre componentes stateful do JSF e EJBs stateful.

JSF não é dos frameworks que eu mais goste, mas realmente essa característica utilizada pelo Seam faz sentido em alguns dos projetos que eu participei. Por exemplo, alguns casos de uso envolvem fluxos com algumas telas, e é necessário guardar os dados ao longo do fluxo de um caso de uso. Entretanto, muitas vezes não é necessário que os dados permaneçam disponíveis para outro caso de uso, então o escopo de sessão é maior do que esta necessidade específica.

Este escopo do qual estamos falando é o escopo de conversação, e eu já sabia que o JSF oferecia algo neste sentido, mas eu não tinha ainda parado pra pensar muito sobre isso. Os dados neste escopo têm o ciclo de vida igual ao de uma conversação, que mapeia bem o fluxo de um caso de uso.

No caso do Seam, ele faz uso deste escopo de conversação para 2 coisas principais. Ele consegue manter os dados vivos por vários requests sem usar o HttpSession, o que é positivo, pois sabemos que é difícil escalar o HttpSession. Além disso, ele resolve o problema de casos em que o usuário usa o back do browser e submete novamente os dados referentes a um fluxo que ele já havia concluído.

No último projeto que eu participei com formulários de mais de uma etapa, consegui resolver esse problema do back do browser com uma solução customizada simples. Quando eu criava as etapas eu criava um hash aleatório e associava a cada uma das etapas que o usuário fosse preencher. Dentro do formulário eu colocava um campo hidden contendo esse hash, e quando o usuário submetesse o formulário conseguiria identificar qual etapa ele estava preenchendo. No final da “conversação” eu limpava esses hashes das etapas que o usuário preencheu, e caso ele tentasse submeter novamente os dados, o hash não estaria mais presente e o submit não seria aceito.

Entretanto, neste projeto eu colocava os dados no HttpSession e destruía o HttpSession no final do fluxo. Nesta situação seria mais interessante usar esse escopo de conversação, pois eu deixaria de pendurar dados no HttpSession e pouparia recursos do servidor.

Felizmente eu verifiquei ontem mesmo que o Spring Web Flow também suporta esse escopo de conversação, e então fica para mim o dever de casa de conhecer o Web Flow e passar a utilizar essa abordagem. O Spring MVC é atualmente o meu framework web Java preferido, e foi ótimo saber que eu não precisaria de JSF para ter uma solução para este problema

Com a minha mudança de alocação da Globo.com para a Globosat, continuo trabalhando bastante com integração de aplicações, mas agora com um ferramental e paradigmas diferentes.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

A documentação do Ibatis não explica adequadamente como funciona o mecanismo de Lazy Load do framework, e como este conhecimento é importante e útil, resolvi explicar brevemente por aqui.

Para habilitar o mecanismo de lazy load, é necessário declarar o elemento settings no sql-map-config, como o exemplo a seguir:

<sqlMapConfig>
	<settings
		cacheModelsEnabled="true"
		enhancementEnabled="true"
		lazyLoadingEnabled="true"
		maxRequests="128"
		maxSessions="10"
		maxTransactions="5"
		useStatementNamespaces="false"
		defaultStatementTimeout="5"	/>
</sqlMapConfig>

Nestas configurações, dois elementos são importantes. O parâmetro lazyLoadingEnabled habilita globalmente o uso de lazy loading no framework. Sem declarar esse parâmetro, todas as buscas serão eager, possivelmente gerando uma grande quantidade de acessos ao banco, dependendo da estrutura de classes.

O outro parâmetro importante é o enhancementEnabled. Com ele habilitado, o Ibatis usa proxies cglib no mecanismo de carregamento das classes, e ele aumenta o escopo do carregamento lazy.

Com o enhancement desligado, serão carregadas de forma lazy apenas as coleções de um objeto, como a lista de produtos de um pedido. Com o enhancement ligado, é feito também o carregamento lazy de atributos complexos de um objeto, como o endereço de entrega do pedido.

Este mecanismo é bem simples de utilizar, e ajuda bastante, pois não precisamos tratar disso no código da aplicação.