Spring Blaze DS 1.5 a caminho…

Dia 02 deste mês foi anunciado no site do SpringSource a disponibilidade da versão 1.5.0.M1 do Spring Blaze DS Integration. Pra quem não conhece este projeto, ele é responsável por abstrair a configuração de aplicações flex/air que utilizem o projeto BlazeDs como middleware de integração com backend java para invocações remotas, mensageria e serviços de push providos pela própria arquitetura da Adobe.

O BlazeDS é extremamente popular por ser um subset free do poderoso Adobe LiveCycle Data Services ES2 da Adobe, que apesar de bem mais limitado (vide quadro comparativo), oferece o mínimo necesário para desenvolvimento de uma aplicação. Até a hora que você decide utilizar alguma solução ORM em seu projeto…

Utilizando a versão 1.0.x do Spring Blaze DS, lá vamos nós tentar retornar uma entidade que possui uma coleção não carregada , em um típico mapeamento 1:N: um grupo que possui uma coleção de usuários, e quando vem o callback..o clássico e demoníaco “Session is closed”. Mas se eu não tentei acessar a coleção de usuários em momento algum, por que cargas d’água essa exceção está sendo lançada??? Maldita serialização de objetos !!

Simplesmente queremos recuperar o nome do grupo pra exibir em um Accordion na interface flex, e assumamos um cenário onde Open Session In View não é bem vindo. O livro Professional Blaze DS de Shashank Tiwari  fala sobre dois adapters Blaze DS open-source para cenários ORM: dpHibernate e Gilead. Ambos permitem carregamento tardio na camada flex(via geração de proxy’s Action Script), mas ferem brutalmente seu modelo de negócio por forçarem ao uso de herança nos POJO’s de seu domínio. Outra solução seria utilizar o GraniteDS…

Voltando à exceção, o que acontece é que ao tentar serializar o POJO na camada Java e enviá-lo ao flex, o objeto que será convertido em Action Script é iterado atributo a atributo para que seja feita a sua criação. Mesmo que você queira acessar apenas o bendito nome, ele vai invocar o método getUsuarios do objeto Grupo, e como o proxy do mesmo continua lá após fechada a sessão..pow!

Problema bastante chato, resolvemos lá no trabalho criando um aspecto que itera pelo objeto após o fechamento da sessão do Hibernate( e antes da serialização do BlazeDS), que faz o papel sujo de desconsiderar os objetos proxiados pelo Hibernate..

Com o upgrade para esta versão 1.5 esse problema não será mais ocorrente pois foi incorporada uma solução elegante para este problema(após muitos pedidos da comunidade), conforme documentação .

Atualização de dependências para o Spring 3, BlazeDS 4 são itens relevantes para o upgrade da versão do Spring Blaze DS Integration em seu projeto, mas sugiro fortemente a adoção desta nova versão considerando o cenário exposto. Ufa, um motivo a menos pra não ser obrigado a adotar o LiveCycle Data Services Até o próximo post !