Depurando o código simplificado, percebi que o objeto retornado permanece intacto até o momento em que atravessa o EJB de volta para a Action (através do JNDI/EJB). Nesse momento, a sessão armazenada em FacetObjectsVO.values.session é anulada (setada em ‘null’) em algum ponto da série de chamadas entre a camada EJB e a camada WEB. A sessão permanece, mas na hora dela ir para a View, é como se houvesse um mecanismo, ou do Struts, ou do EJB3, que esteja desacomplando o objeto, como num ambiente desconectado.
Confirma essa análise, Paulo?
Vou baixar os sources do JBoss AS pra aumentar minha superfície de depuração…
É o seguinte: sua classe FacetObjectsEJB faz a busca utilizando essa outra classe estatica (era melhor receber por injecao, e essa quebra em VOs, BOs, etc vai acabar te atrapalhando, alem dos daos que estendem um do outro). Depois, quando o objeto FacetObjectsVO passa do tier do JBoss pro tier do tomcat, tudo que não foi inicializado não ser amais inicialziado (nao da para voltar atras do tier, seria muito custoso caso acontecesse n+1 invocacoes remotas),e de nada vai adianta o open session in view ja que ela ja é considerada fechada (pois objeto foi serializado para o outro tier, ele esta detached).
A solucao ai é voce fazer um select com fetch join nessa query especifica para, nesse caso, o relacionamento com values ser eager.
Para voce apenas testar, no seu FacetObjectsEJB, faca a inicializacao da proxy dinamica que esta lazy, com:
public FacetObjectsVO fetchFacet(String pFacetTitle)
{
FacetObjectsVO vo = BOFactory.getFacetObjectsBO().fetchFacet(pFacetTitle);
Hibernate.initialize(vo.getValues());
return vo;
}
Me retornou essa exception:
Tentei resolver removendo temporariamente o Tier do EJB, trazendo o DAO pra dentro da Action, e percebi que meu mapeamento estava com uma “pequena” falha…
Com isso eu consegui a saída na tela. Eu entendi a solução q vc propôs dentro do BO, mas ela retorna:
Já a solução do fetch dentro da query, envolveria modificar a estrutura do DAO, mas mesmo assim vou testar. A solução mais próxima da minha realidade que consegui achar pesquisando foi Remote Lazy Loading, envolve uso de Tuplizer customizado pra retornar um Proxy também customizado, pra ativar de forma transparente os objetos Lazy… ainda estou prourando mais sobre isso pois não existe nenhuma receita de bolo pra isso, o mais próximo que cheguei foi uma solução com Annotations (h3t.sf.net) e o artigo do Premkumar Rajendran:
Marcos, “javax.ejb.EJBException: org.hibernate.AssertionFailure: force initialize loading collection” da quando a inicialziacao ja foi feita. agora que voce tirou o tier de ejb fora do caminho, tente com o open session view apenas que vai funcionar (pode tirar o initialize).
Paulo, analisando o código, percebi que o erro “SerializationException” estourou por causa do mapeamento errado (property ao invés de many-to-one+lazy) o que fez com que o objeto fosse inicializado mais cedo (de acordo com o q vc disse). Porém quando consertei o mapeamento, voltei a ter o “LazyInitializationException”. Após isto, quando coloco o Hibernate.initialize no BO, funciona. Isso tudo ocorreu com o filtro do Hibernate já ativo (sessão ativa na View).
Como minha idéia é deixar o código mais simples possível sem esses POGs no BO, vou ter q pensar na solução do Remote Lazy Loading (sobrescrever proxy). Valeu ai!
marcos, reescrever a proxy vai dar uma boa trabalheira. se der pra voce tirar o tier do ejb, seria fantastico… (ou usar ejb 3.1 que agora tem objetos locais, usa-lo apenas como Ioc). abracos