@PreDestroy in @ViewScoped

A bean of type @ViewScoped will be active as long as the requests are made to the same page. When you make a request to another page or another bean the scope is cleared.

When working with JSF it is very important to know life cycles well. I do not quite understand when you use the term "force" the destruction, but I think it would be more appropriate to use a @RequestScope , which will be created at the beginning of a request and destroyed at the end of the request. >

There is no advantage between @ViewScoped on @SessionScoped because both are used for different purposes. A bean of type @SessionScoped is instantiated once, which is when a user logs into your app and destroyed when the session is terminated.

EDIT As I mentioned in some comments in other answers to this question, it is very important to separate the ManagedBeans by "concept" (eg, PessoaBean, EnderecoBeam, etc ...) so that ViewScope caters correctly. If you need to access other beans, remember that it is possible to inject one ManagedBean into another, so you will not kill your main bean.

  

1 - Is it problematic for the bean to never be destroyed and always be created every time the page is accessed?

Things like this are the reason I do not recommend JSF for any new project.

Yes, there is considerable advancement in API and implementations, but this is not a solution to JSF's recurring problems.

  

2 - Is it valid for me to force the bean to be destroyed 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 greatly abstracts how a web system works, we often have to use artifacts to get the needed tuning .

On a system I worked with, which used JSF 1.1, I had to implement a session cleanup routine each time a menu was accessed. This was because the system was legacy and developers had the habit of putting everything in session scope. There was no way to refactor the system.

Basically, I "intercepted" each call to a menu option to identify when the user would exit from one screen to another. So I ran the session map and removed the entries, except some that were really "global". Differentiation was done based on prefixes in attribute names.

  

3 - What is the advantage of @ViewScoped over @SessionScoped in this context?

@ViewScoped tries to automate the scenario I described above. It works fine on a screen that always uses Ajax to perform operations.

However, a simple CRUD with search, add, change, and delete screens can not make use of this feature. To begin with, if the user performs a search and changes an element, all filters are lost.

At the end you realize that using the session improves usability in the sense that some values are needed that are stored for the user. On the other hand, using the session also causes problems because the user can open multiple tabs and windows and system behavior becomes unpredictable.

And, contrary to what might seem, the View scope generates the same thing. If the user opens several tabs with the same page, one of them will change the status of the other tabs. Some people think that View Scope solves JSF problems, but it only minimizes some and actually causes others.

As a result you end up with requirements to use at least strangers like: the system can not be used in more than one window at a time .

At the end of the day, the conclusion is that reasonable usability is only achieved with the request scope ( Request Scope ). However, the advantage of a component based framework like JSF is completely lost. Even multiple components (think of dataTable of PrimeFaces) no longer work correctly with the request scope. And even the one that works ends up giving as much work as if you were doing things "at hand."

And, with all this, it was concluded that an action based framework should have been used from the outset.