1 - It is problematic that the bean will never be destroyed and will always be created every time the page is accessed?
Things like this are the reason I don’t recommend JSF for any new project.
Yes, there is considerable progress in API and implementations, but this has not been accompanied by a solution to recurring JSF problems.
2 - It is valid to force bean destruction using redirect?
Everything is valid as long as it fulfills the necessary function without causing unwanted side effects.
Unfortunately, when we use a framework that abstracts a lot the operation of a web system, we often have to use tricks to be able to do the tuning necessary.
On a system I worked on, which used JSF 1.1, I had to implement a session cleaning routine every time a menu was accessed. This was because the system was legacy and the developers had a habit of putting everything in session scope. There was no possibility of refactoring the system.
Basically, "Interceptei" each call to a menu option to identify when the user output from one screen to another. So I would scroll through the session map and remove entries, except for some that were actually "global". Differentiation was made based on prefixes in attribute names.
3 - What is the benefit of @Viewscoped over @Sessionscoped in this context?
The @ViewScoped
tries to automate the scenario described above. It works well on a screen that always uses Ajax to perform the operations.
However, a simple CRUD with search, inclusion, alteration and exclusion screens cannot make use of this resource. To begin with, if the user does a search and changes an element, all filters are lost.
In the end you realize that using the session improves usability in the sense that some values are required to remain stored for the user. On the other hand, using the session also causes problems because the user can open multiple tabs and windows and the behavior of the system ends up becoming unpredictable.
And, contrary to what it may seem, the scope of View generates the same thing. If the user opens several tabs with the same page, one of them will change the status of the others. Some people think that the View Scope solves JSF problems, but it only minimizes some and actually causes others.
As a consequence you end up with strange usage requirements at least as: the system cannot be used in more than one window at the same time.
At the end of the day, the conclusion is that reasonable usability is only achieved with the scope of the request (Request Scope). But then you completely lose the advantage of a framework Component based like JSF. Including several components (think about dataTable
of Primefaces) no longer function properly with the scope of request. And even what works ends up giving so much work as if you were doing things "in hand".
And, with all this, it was concluded that from the beginning a framework should have been used action based.
There is a bug regarding the behavior you mentioned, the
@preDestroy
is only called when the session expires, generating memory Leak. They said it was fixed in version 2.2 of the specification in 2012 (https://java.net/jira/browse/JAVASERVACES_SPEC_PUBLIC-905). I found Issue in the implementation of Jboss Wildfly (https://issues.jboss.org/browse/WFLY-785) and it has not been solved yet. I think it depends on each Container, try searching if your container fixed this bug.– Wakim
In the version of Glassfish I am using (3.1) this supposed bug persists. I wonder if it is harmful to the application to let you create several Bens in memory without destroying them, as is the case with @Viewscoped. One solution I found was to use redirect whenever browsing another page, hence yes the bean is destroyed.
– electus
As I mentioned, there will be the memory problem Leak, let alone
statefull
for your bean, worse. The solution that gave is not bad, I’m just not sure of the side effects.– Wakim