Head First Book Chapter 6 mock questions Question No. 7 (page 274 - if you search from PDF, it shows me as page 271). The question is to select "true" statements and the following is mentioned as true statement:
Attributes bound into a session are available to any other servlet that belongs to the same ServletContext
Can somebody help me understand how this could be true? Isn't any attribute bound to a session available to the only servlets that are accessed in the same session? How could it be available to all servlets in the web app (refer the phrase - same ServletContext? The answer mentions this as true statement.
Very sorry for that wrong information Pad Ven, Here is the servlet specification, have a look on that.
SRV.7.4 Binding Attributes into a Session
A servlet can bind an object attribute into an HttpSession implementation by name. Any object bound into a session is available to any other servlet that belongs to the same ServletContext and handles a request identified as being a part of the same session.
Isn't any attribute bound to a session available to the only servlets that are accessed in the same session? How could it be available to all servlets in the web app (refer the phrase - same ServletContext?
For me, this question was also very awkward.
Session attributes are visible for the servlets which belongs to the same session.
By the way, there is a question: what should you understand by "same ServletContext".
Should you treat two identical applications in a cluster (working on different JVMs) as using the "same ServletContext"?
This is true if you understand it as a "logic context", but not when you treat it as a ServletContext object. This ServletContext object will be different on both JVM's but you can still access session attributes from both of them.
Please straighten me if I'm not right.
OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
Create a web application.
Create a Servlet1 class which will override the doGet(...) method and sets an attribute in session scope.
Create a Servlet2 class which will override the doGet(...) method and reads an attribute in session scope.
Now enter Servlet1 mapped URL and then enter Servlet2 mapped URL.
If Servlet2 prints the value set in Servlet1, well, this is basicaly what you were asking for:
Any object bound into a session is available to any other servlet that belongs to the same ServletContext and handles a request identified as being a part of the same session.
Joined: Mar 12, 2010
Thanks a lot for this example.
Ya,I agree that Servlet2 will print the value set in Servlet1,
what is confusing me is the text 'same ServletContext'
How can we say that Servlet1 and Servlet2 belong to same ServletContext? Is it something related to context path..? or does it mean like any servlet belonging to the same application..?
Yes, you can say that the same ServletContext is the same as an application.
It's the yourApplication directly under i.e. tomcat_root/webapps/yourApplication
You can say that Servlet1 and Servlet2 belong to the same ServletContext (application) by taking look at the web.xml file under tomcat_root/webapps/yourApplication/WEB-INF/web.xml and also by noticing that *.class files are located under tomcat_root/webapps/yourApplication/WEB-INF/classes package structure.
But remember that (as mentioned in previous posts) that your single application can be deployed in clustered environment; then all copies of your application will have their own ServletContext (each per JVM).
Joined: Mar 12, 2010
Ya, Thanks for the reply. It makes sense to me now...
But again regarding clustered environment, as on page 257 of HeadFirst, it says only HTTP session objects move from one VM to another.
All other things are copied.
Even if wwe see in the figure at page 257, only session object is different for both VM1 and VM2, all other things like servletcontext, servlet config are copied on both the JVMs.
Does not it mean that applications in clustered environment also share the same servletContext?