JSF: saveState ou KeepAlive em Beans request com objetos não serializable
7 respostas
C
ccalixto
Olá pessoal,
Estou com um problema relacionado a beans Request/Session.
Por questões obvias não devemos encher as aplicações de beans Session, somente quando for necessário.
Quando se precisa aumentar o tempo de vida de um bean Request podemos usar o saveState (MyFaces) ou o KeepAlive (a4j). E ai que surgiu o problema que originou este tópico:
Nos meus beans há alguns objetos do Java que não são Serializable:
uma instância da classe ResourceBundle
como eu uso Spring, ele cria também um Proxy da minha classe de negócios, e esse proxy tb não é serializable.
algumas classes de componentes JSF linkadas dentro do bean (pela propriedade binding) também não são serializable.
Logo, como vocês fazem para utilizar o KeepAlive ou saveState em beans com estes tipos de objetos?
Será que eu estou cometendo alguma gafe? hehehe :oops:
Ainda gostaria de entender por que algúem que desenvolve web acredita que request é sempre melhor que session mesmo quando o objeto é utilizado em várias requisições de páginas. Tenho uma impressão de request é ruim nesses casos pois há muita gambiarra pra manter o estado e há o problema da criação e destruição constante de objetos, podendo inchar o consumo de memória (ou você acha que os objetos sem referência sempre estarão efetivamente destruídos quando os novos objetos da próxima requisição forem alocados?) e fazer com que o garbage collection trabalhe muito.
Bom, mas vamos lá. Quanto a ResourceBundle, nem se preocupe com esse objeto. O JSF consegue administrar internacionalização com a tag f:loadBundle. Se você tem um managed bean que use um objeto spring (que não é singleton), não há muito jeito, tem que por no session. E evite os bindings ao máximo, se for o caso coloque num managed bean separado do managed bean responsável pelo negócio. Não há muito sentido manter um bind de um componente que não está mais na tela.
C
ccalixto
Olá Leonardo,
Eu concordo plenamente com você, por isso que comentei que devemos usar beans Session quando necessário. E neste caso que vc comentou o Session seria necessário.
No meu caso, estou desenvolvendo uma aplicação em Ajax e se eu não conseguir utilizar o KeepAlive todos meus Beans vão ter que ser do tipo Session. Ai eu acho que arquiteturalmente muitos estarão incorretos, já que os beans serão utilizados em algumas páginas, e após esta utilização não tem porque eles ficarem na sessão.
No caso do Spring é um objeto setado pelo org.springframework.web.jsf.DelegatingVariableResolver, e eu gostaria de saber como vocês fazem com isso? Pois eu estou recebendo um NotSerializable exception.
Valew pessoal!!!
Claudiney
humberto.lima
Já pensou em colocar os atributos q nao serão serializados como transient?
[]´s
Humberto Lima
gilbueno
NOSSA, me desculpe mas, QUE ABSURDO VCS ESTÃO FALANDO!
Sempre que possivel NÃO USE SESSÃO
problemas de usar sessão:
problemas de escalabilidade
:se sua aplicação crescer muito vc terá que usar clusters com estado, alem de muito caro é muito mais lento do que apenas deixar computadores atendendo requisições alternadamente;
performance
:vcs devem saber que uma aplicação que guarda muitas coisas na memória acaba ficando cada vez mais lenta;
entre outros.
O JSF é péssimo com RequestScoped, mas acho que existem alternativas melhores para esta situação do que usar Sessão
E
edifreittas
bom dia a todos.
olá amigos não tenho bagagem para argumentar o respeito do tema, pelo contrário
tenho algumas duvidas se puderam saná-las ficarei muito grato.
o calixto comentou:
sou iniciante e gostaria de saber como fazer o mesmo no adf faces.
agradeço a todos obrigado.
gilbueno
nunca usei adf faces, na verdade prefiro não usar estas bibliotecas que não fazem parte da especificação do JSF.
E
edifreittas
ok gilbueno no momento eu não tenho essa escolha kkkkk.
mais valeu assim mesmo continuo pesquisando se eu consegui
antes que alguém aqui possa me ajudar eu posto a solução.
