• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

SessionScope bean works as viewscoped bean

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all!
I have found a very unusual behaviour when running a small test JSF web APP on Tomcat 7.0.71.

Basically I have found that a sessionscoped bean works as a viewscoped bean (what means that the bean is recreated everytime it is called). This happens from Tomcat 7.0.54 to last Tomcat 7 version(7.0.71 now). The same test APP works fine with prior versions (from 7.0.53 down). Same happens with Tomcat 8 (don't remember the exact version when this starts happening).What change was perform in Tomcat from version 7.0.53 to version 7.0.54 that causes this behaviour?

I'm using Eclipse Mars.2 with Java 1.7, JSF Mojarra 2.2, Primefaces 6.0, Tomcat 7.0.70, Spring 3.2.3 and Hibernate 4.3.8.

I'm creating a very simple web application with a main page with a viewscope bean (javax.faces.bean.ViewScoped) that loads the locale from a session bean. Such page contains some internationalized text and a comboBox with a list of languages that whenever is changed changes the LOCALE in a session bean and navigates to the same page to refresh all page text.

In order to keep the current LOCALE value I use a session bean (javax.faces.bean.SessionScoped) which whenever is created with its constructor (what is supposed to happen just once) loads a default LOCALE.

To my surprise I found that no matter what language I chose in the comboBox only the default laguage is loaded. When I debugged I found that the constructor of the session bean is called several times every time I access to it, which obviosuly is causing the default language to be loaded time after time without caring for my selection in the combo.

This has no sense, it is not the normal behaviour of a session bean. The session bean seems to be created everytime it is called.

**WEB.xml**

**Index.xhtml**


**IndexBB.java**

**Sesion.java**

Additional info in this stackoverflow question I performed:

http://stackoverflow.com/questions/39645077/jsf-sessionscoped-bean-created-several-times?noredirect=1#comment66740818_39645077

Thanks in advance!
 
Jesus Schneider
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It works with Tomcat 8.0.1 and doesn't work with Tomcat 8.0.11... What changed in that Tomcat versions to create such behaviour?
 
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Session scope and View scope are 2 distinct things. JSF Session scope is the same thing as J2EE session scope - an object is constructed and it is stored in the HttpSession's object map. The only difference between JSF and raw J2EE is that JSF can do the construction and storage for you automatically (Managed Beans).

There is no J2EE/JEE equivalent to View scope, since Views are an abstraction not supported directly by J2EE primitives. In actuality, View Scope is just Session Scope with the refinement that when JSF navigates to a new View, the view-scope object(s) of the old view are removed from scope. NOT deleted, mind you - if there are hanging references directly to those objects, the objects will remain (not be garbage-collected) - but no longer referenced from the HttpSession.

I cannot guarantee what would happen to view-scope objects if, instead of using JSF navigation or link tags you did a raw URL jump to a new page. If the new page wasn't a JSF page, then I'd expect the view-scope object(s) to remain attached to the HttpSession, If the new page was a JSF page, maybe the new view initialization code would detect and remove them, maybe not. I haven't read that part of the spec to see if it mandates a particular behavior.

All I can say is that if you rely on perceived behavior on session and view scope objects rather than on spec-defined behavior, you'll probably regret it sooner or later.
 
Jesus Schneider
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Session scope and View scope are 2 distinct things. JSF Session scope is the same thing as J2EE session scope - an object is constructed and it is stored in the HttpSession's object map. The only difference between JSF and raw J2EE is that JSF can do the construction and storage for you automatically (Managed Beans).

There is no J2EE/JEE equivalent to View scope, since Views are an abstraction not supported directly by J2EE primitives. In actuality, View Scope is just Session Scope with the refinement that when JSF navigates to a new View, the view-scope object(s) of the old view are removed from scope. NOT deleted, mind you - if there are hanging references directly to those objects, the objects will remain (not be garbage-collected) - but no longer referenced from the HttpSession.

I cannot guarantee what would happen to view-scope objects if, instead of using JSF navigation or link tags you did a raw URL jump to a new page. If the new page wasn't a JSF page, then I'd expect the view-scope object(s) to remain attached to the HttpSession, If the new page was a JSF page, maybe the new view initialization code would detect and remove them, maybe not. I haven't read that part of the spec to see if it mandates a particular behavior.

All I can say is that if you rely on perceived behavior on session and view scope objects rather than on spec-defined behavior, you'll probably regret it sooner or later.



Hello Tim! Nice to see you are still here!
I don't have a so in deep knowledge of the @SessionScoped or the @ViewScoped beans, I understand the basis of its behaviours, life cycle and so on...
I have been using such beans types for a long time with same Tomcat version (7.0.41) with no problem at all. Now, as stated in my post, with the same test code and newTomcat version (7.0.71) the APP fails.
My logic tells me that if the code (WAR file) is the same something has changed from Tomcat 7.0.53 to tomcat 7.0.54 in the way of managing such beans.
Any clue?
Thanks in advance!!
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since Tomcat doesn't support JSF at all, I have no clue.

JSF under Tomcat is entirely handled by JSF libraries in the webapp - unlike full-stack JEE servers - Tomcat has no JSF functionality of its own.
 
Jesus Schneider
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Since Tomcat doesn't support JSF at all, I have no clue.

JSF under Tomcat is entirely handled by JSF libraries in the webapp - unlike full-stack JEE servers - Tomcat has no JSF functionality of its own.



I know that Tomcat is not like Glasssfish or Weblogic and doesn't have any library at all, that's the reason why I'm so shocked.
But the fact is that the example I have developed is VERY simple and from one Tomcat version to another it stops working properly.
You are cordially invited to make the same test I did, it will take you 5 minutes...

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

My JSP-based app has web.xml with session-timeout=0.

On my NAS server (ASUSTOR, Linux/ARM) with Tomcat 7.0.47, this works as expected, as my session scoped JSP object stays the same (the object reference never changes).

When I deploy the same war file on Tomcat 8.0.32 on Ubuntu 16.04 64 bit PC, the object is replaced by a new reference on each request.

The original question tells a smilar story. I am not using JSF, only JSP.
 
Ejner Borgbjerg
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On Ubuntu 16.04 LTS, with Tomcat 7.0.82, it works like expeced.

So something must have happened between 7.0.82 and 8.0.32.

 
Ejner Borgbjerg
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When installing 8.5.24 by download + unzip, then behavior is as expected.

So its also possible that the difference lies in the choice of installation method.
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Somewhere right about release 8.0.32, a radical change was made to Tomcat's deployment mechanism. Radical enough that I'm surprised that it didn't change at a major release version.

Every release of Tomcat back to at least Tomcat 4 had the property that when you deployed a WAR file to TOMCAT_HOME/webapps and the default settings were in effect, Tomcat would unzip ("explode") the WAR file into a correspondingly-named directory.

The exploded WAR was the definitive copy of the webapp and once exploded, it remained definitive even if you copied in a newer WAR file. That is, if you have a file named xyz.war and copied it to TOMCAT_HOME/webapps, Tomcat would unzip it to TOMCAT_HOME/webapps/xyz and run that webapp. Copying a new xyz.war would not do anything to the running webapp - you would have to delete the xzy directory before Tomcat would accept the new xyz.war. Even stopping and restarting Tomcat would not do it.

Starting in Tomcat 8.0.32, this behavior changed. In Tomcat 8.0.32 and later, copying in a new xyz.war will cause Tomcat to replace the existing xyz directory automatically. If you do that while the Tomcat server is running, effectively Tomcat will stop the webapp (destroying active session objects), explode the war file, the start the webapp using the new exploded WAR.

This is probably what you are seeing.
 
    Bookmark Topic Watch Topic
  • New Topic