Problema com dependencia lazy.

Não estou entendendo porque estou tendo problemas com lazy no jsp....

exemplo tenho um objeto usuario que tem um uma lista de permissao ( LAZY )

executo o método de carregar usuario e quando vou tentar acessar as permissao no jsp (usuario.permissao) da problema com lazzy dizendo que minha session ou foi fexada ou esta nulla.

porém fiz o teste logo após carregar o usuario com "getSession().isOpen()" e me retornou true.

e nem se quer chegou no commit do meu interceptor:
erro esta dando no stack.next porém depois de executar toda minha logica e na ultima linha do meu código a ser executada eu verifiquei a session e ela esta aberta =S

alguem tem uma ideia do que pode ser? ou alguma forma melhor de se fazer?

GUJ Ranger Membro desde: 24/01/2008 22:05:47 Mensagens: 794 Offline

eu uso JPA em aplicação Desktop, mas ja fiz um sisteminha Web...

em Desktop eu dou o commit e depois quando faço select eu dou refresh no objeto...

quando fiz pra web eu fiz um Servlet de filtro para trabalhar com conexao no banco de dados e manipular as sessões justamente para resolver problemas com lazy e eager.

vlw

JavaChild Membro desde: 20/08/2009 22:47:36 Mensagens: 127 Offline

Tive um problema com o lazy e sessão. Não sei se é o mesmo problema mas...

O problema era quando gravava na sessão, ele gravava null por causa do lazy.

Resolvi usando get no lugar de load, só para essa situação especifica.

Se você está usando Vraptor não há motivos para controlar o ciclo de vida das sessions e transações manualmente. Aliás isso já é um assunto muito discutido por aqui, e toda semana acaba aparecendo um tópico desses.

http://guj.com.br/posts/preList/208158/1057667.java#1057667
http://guj.com.br/posts/preList/207568/1054694.java#1054694
http://guj.com.br/posts/preList/205888/1048044.java#1048044

garcia-jj wrote:Se você está usando Vraptor não há motivos para controlar o ciclo de vida das sessions e transações manualmente. Aliás isso já é um assunto muito discutido por aqui, e toda semana acaba aparecendo um tópico desses.

http://guj.com.br/posts/preList/208158/1057667.java#1057667
http://guj.com.br/posts/preList/207568/1054694.java#1054694
http://guj.com.br/posts/preList/205888/1048044.java#1048044

problema pra mim é que não posso simplesmente usar a injeção de dependencia (da session) nos dao pq eles ficam em outro modulo EJB e nao acesso eles diretamente no projeto web chamo um serviço que nele cria o dao e insere a session que mandei ali do userInfo .

JavaChild Membro desde: 20/08/2009 22:47:36 Mensagens: 127 Offline

Jingle,

Você verificou se a lista de permissão não está nula?

eu tinha o seguinte erro:

que acontecia porque o atributo na sessão que eu tentava acessar estava nulo.

GUJ Hacker Membro desde: 08/07/2007 00:08:14 Mensagens: 6394 Offline

quem está gerenciando a abertura e fechamento das sessions?

jingle wrote:problema pra mim é que não posso simplesmente usar a injeção de dependencia (da session) nos dao pq eles ficam em outro modulo EJB e nao acesso eles diretamente no projeto web chamo um serviço que nele cria o dao e insere a session que mandei ali do userInfo .

Pois é, mas aí você tem um erro de desenho. Em um módulo EJB se você tem um entity Customer e você precisa jogar para fora do módulo EJB você precisa de um DTO. Muita gente jura que não, mas se você jogar sua própria entidade para fora do módulo EJB você terá esses problemas.

Como você está usando no seu projeto? Você usa o Web Profile do JEE6? Ou o módulo EJB é em um JAR empacotado no EAR com o WAR da aplicação web?

Lucas Cavalcanti wrote:quem está gerenciando a abertura e fechamento das sessions?

Pelo comentário dele quem controla isso é o módulo EJB.

jingle wrote:problema pra mim é que não posso simplesmente usar a injeção de dependencia (da session) nos dao pq eles ficam em outro modulo EJB e nao acesso eles diretamente no projeto web chamo um serviço que nele cria o dao e insere a session que mandei ali do userInfo .

This message was edited 3 times. Last update was at 08/06/2010 08:36:10

Olá primeiramente obrigado pelas respostas.

Lagaffe: Você verificou se a lista de permissão não está nula?

se eu tentar obter o valor da lista de permissao ainda na minha controller ela vem de acordo, mas na jsp acusa que já fechei ou esta null a session.

Lucas Cavalcanti: quem está gerenciando a abertura e fechamento das sessions?

minha classe connection que esta controlando que esta dando open session já tentei fazer singleton como já tentei utilizando ThreadLocal, já tentei controlar as transaçoes nos interceptor do ejb e também tentei nos interceptor do vraptor.

garcia-jj: Pois é, mas aí você tem um erro de desenho. Em...

Estou usando o jar do ejb + war do projeto web dentro do ear.
hmmm você diz ter um DTO pra cada modelo? mas não acaba se tornando muito cansativo fazer isso? apesar de me parecer que vou ter bastante código semelhante estou começando a achar que essa é uma excelente alternativa.

Jingle, há uma confusão. Você em um momento me disse que quem controla a sessão do hibernate é o módulo EJB, em outro momento diz que é uma classe sua usando thread-local.

Afinal, quem é que faz o que?

garcia-jj wrote:Jingle, há uma confusão. Você em um momento me disse que quem controla a sessão do hibernate é o módulo EJB, em outro momento diz que é uma classe sua usando thread-local.

Afinal, quem é que faz o que?

me expressei mal, é uma classe (Connection) que se encontra em outro modulo EJB.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

garcia-jj wrote:... de desenho. Em um módulo EJB se você tem um entity Customer e você precisa jogar para fora do módulo EJB você precisa de um DTO. Muita gente jura que não, mas se você jogar sua própria entidade para fora do módulo EJB você terá esses problemas. ...

Gente,
posso dar 1 pitaco: Garcia, o jingle não poderia usar a abordagem de Persistência: modo StateFull??! (Não tem como usar StateFull sem Seam??)

jingle wrote:Estou usando o jar do ejb + war do projeto web dentro do ear.
hmmm você diz ter um DTO pra cada modelo? mas não acaba se tornando muito cansativo fazer isso? apesar de me parecer que vou ter bastante código semelhante estou começando a achar que essa é uma excelente alternativa.

Para sistemas remotos é obrigatório usar DTO, mas em aplicações "monolíticas" tem gente que usa exportar as entidades. Um DTO não é exatamente um espelho do que é sua entidade.

Eu já tinha escrito isso há alguns dias em outra thread: http://guj.com.br/posts/list/15/204519.java#1039241

This message was edited 1 time. Last update was at 08/06/2010 09:50:20

derlon wrote:

garcia-jj wrote:... de desenho. Em um módulo EJB se você tem um entity Customer e você precisa jogar para fora do módulo EJB você precisa de um DTO. Muita gente jura que não, mas se você jogar sua própria entidade para fora do módulo EJB você terá esses problemas. ...

Gente,
posso dar 1 pitaco: Garcia, o jingle não poderia usar a abordagem de Persistência: modo StateFull??! (Não tem como usar StateFull sem Seam??)

Sim, há como usar. Stateful é do EJB e não do SEAM. Porém um bean stateful não difere muito de um stateless nesse caso que ele tem. Basicamente a diferença entre stateful e stateless é que no stateful você tem uma instância somente sua, e você pode usar e abusar dos atributos de classe. Em um stateless você recebe uma instância compartilhada, e todos os atributos de classe são compartilhados, já que a instância é a mesma. Você está confundindo (acho eu) com o entity-manager extended, que funciona apenas para EJB Stateful. Mas isso não altera em nada o caso do lazy-load, pois se você tentar carregar uma coleção lazy-loaded no JSP terá o mesmo erro.

O problema todo é que a especificação é clara: sempre que você sai de um EJB você perde todos os dados do entity-manager. Uma entity-manager não pode sobreviver fora de um container, no caso do uso de EJB com entity-manager gerenciado pelo appserver.

Por isso você precisa usar os DTOs, assim você transforma seu bean conforme o que você precisa para seu caso de uso e carrega já tudo que você precisa. Quando o bean sair do módulo EJB você já terá carregado tudo que você precisa.

Lazy remoto é uma put* gambiarra, e até existe um projeto para isso, o H3T. Mas no próprio site do projeto diz que lazy remoto viola a especificação e que não é aconselhado mesmo. http://www.guj.com.br/posts/list/140211.java#755879

http://h3t.sourceforge.net/

Notícias, artigos e o maior fórum brasileiro sobre Java