Estou com um sério problema em usar um método @PreDestroy em um ViewScoped Managed Bean. O método @PostConstruct é chamado toda vez que realizo uma requisição na tela, e o @PreDestroy nunca é chamado, mesmo que eu saia da tela. Só consegui executar esse método após executar um método que ao fim mandava recarregar a própria página. Gostaria de saber como funciona o ciclo de vida desse ManagedBean, quando ele é descartado pelo servidor e como eu posso ouvir essa ação.
@PreDestroy em ViewScoped JSF ManagedBean [RESOLVIDO]
A
11 Respostas
H
Pesquisei jsf predestroy viewscoped no google. Já de cara achei: http://stackoverflow.com/questions/6368840/predestroy-never-called-on-viewscoped
Fica a dica. [=
R
Taí um dos motivos de eu não gostar de pendurar transações/conexões com banco em sessões ou coisas do tipo …
H
Taí um dos motivos de eu não gostar de pendurar transações/conexões com banco em sessões ou coisas do tipo …Por isso que eu gosto do EJB. Joga tudo de banco para o EJB que ele toma conta das transações. [=
Nunca confiei também de ter o controle de transação nesse tipo de ação.
R
Taí um dos motivos de eu não gostar de pendurar transações/conexões com banco em sessões ou coisas do tipo …Por isso que eu gosto do EJB. Joga tudo de banco para o EJB que ele toma conta das transações. [=Nunca confiei também de ter o controle de transação nesse tipo de ação.
Exatamente!
E mesmo que eu não disponha de um servidor que suporte EJB’s eu faria uma camada de serviços separada, nem que eu precisasse abrir/fechar as transações na mão.
A
é, parece não ter uma solução simples pro problema, então vou fazer de outra forma. Obrigado, até mais.
C
CDI com ConversationScope seria uma boa pedida nessas horas
H
CDI com ConversationScope seria uma boa pedida nessas horasSei mais ou menos como esse escopo funciona.
Mas por curiosidade, se o cara não chamar o método do conversation de close(). Qual o melhor método de tratar isso?
C
Na realidade o conversation tem um propósito diferente do View, sendo que enquanto este é utilizado em chamadas ajax geralmente, o primeiro é um meio de atrelar o ciclo de vida do objeto ao seu workflow, sendo que cabe a voce definir em quais casos seria interessante ele morrer, como por exemplo, uma ação executada com sucesso dentro de uma determinada funcionalidade. Nunca tive um caso no qual o conversation não pode substituir o viewScoped, não é uma substituição trivial, mas cabe a uma análise mais apurada do contexto sobre o qual ele será aplicado.
H
Minha pergunta é pelo fato de quem você tem que executar conversation.begin(); e o conversation.end(); correto?
Ao chamar o conversation.end() todos os objetos que estão na memória voam? Se sim, como é feito para um datatable onde se tem vários itens e varios dialogs para editar os valores do datatable? Se o end() eliminar os objetos da memória você teria chamar o end() ao sair da tela ou coisa parecida, é isso?
estou te perguntando pois você é o primeiro que eu vejo que utilizou essa opção. [=
C
O end seria executado quando a operação fosse finalizada, seja uma troca de tela, ou uma finalização de venda, talvez até a propria dialog tudo depende da modelagem, mas o Conversation requer um esforço lógico maior para poder determinar exatamente o ciclo de vida dos objetos.
Este escopo é peculiar devido a sua aplicação ser maleável, permitindo um maior dominio sobre os escopos.
A
obrigado pela dica clesiussjm, preciso começar um projeto teste pra aprender CDI, nesse caso não vai dar porque não estamos usando, mas meu próximo com certeza vai ser com CDI.
Criado 5 de julho de 2012
Ultima resposta 6 de jul. de 2012
Respostas 11
Participantes 4
Alura POO: o que é programação orientada a objetos? Aprenda os conceitos básicos da programação orientada a objetos, como classes, objetos, herança, encapsulamento e polimorfismo, com exemplos.
Casa do Codigo JavaScript Assertivo: Testes e qualidade de codigo em... Por Gabriel Ramos — Casa do Codigo