Servlets: session tracking

hi
i am a newbie to j2ee. i am currently learning about session tracking in Servlets. i have written a simple program.
this is what its supposed to do:
FirstNameSessionServlet page
accept the first name of the user
submit
LastNameSessionServlet page
it shows the firstname name
show session id
accept the last name of the user
submit
FirstandLastNameSessionServlet page
show the first name
show the last name
show session id
show session attibutenames
FirstNameSessionServlet page output:
first name: textbox
submit
i enter abc into the textbox and click submit
LastNameSessionServlet
Your First Name is : abc(getParameter method used)
Your First Name is : null(getSession method used)
session id: CDFEBEEC7D599C70359AE52DBD1EAAEE session getLastAccessedTime1180087277281
last name textbox
submit
i enter def into the textbox and click submit
FirstandLastNameSessionServlet output page
your first name is: null
your last name is: def
session id: CDFEBEEC7D599C70359AE52DBD1EAAEE
session tracked success
i can't understand the use of getAttribute(); Can anybody please tell my why getAttribute(); is returning null when i am trying to access the firstname variable through this method. what am i doing wrong? thanx for your help
shankha
here is my code
FirstNameSessionServlet.java
[//FirstNameSessionServlet.java
package myname;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class FirstNameSessionServlet extends HttpServlet{
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         doPost(req, res);
    public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         res.setContentType("text/html");
         PrintWriter pw=res.getWriter();
         pw.println("<html><body>");
         pw.println("<form action='/contentnames/uti/LastNameSessionServletpath' method='post'>");
         pw.println("<p>First Name: <input type='text' name = 'firstname'></p>");
         pw.println("<p><input type='submit' value='Enter'></p>");
         String firstname= req.getParameter("firstname");
         HttpSession sess = req.getSession(true);
         sess.setAttribute("firstname",firstname);
         pw.println("</form></body></html>");
         pw.close();
LastNameSessionServlet.java
LastNameSessionServlet.java
//LastNameSessionServlet.java
package myname;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class LastNameSessionServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         doPost(req, res);
    public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         res.setContentType("text/html");
         PrintWriter pw=res.getWriter();
         pw.println("<html><body>");
         pw.println("<form action='/contentnames/uti/FirstandLastNameSessionServletpath' method='post'>");
         String firstname= req.getParameter("firstname");
         int attrib=1;
         HttpSession sess = req.getSession();
         String firstnamesession = (String) sess.getAttribute("firstname");
            req.setAttribute("firstname", firstname);
            req.setAttribute("firstnamesession",firstnamesession);
            //req.setAttribute("firstname",firstname);
         pw.println("<p>Your First Name is : "+firstname+"(getParameter method used)</p>");
         pw.println("<p>Your First Name is : "+firstnamesession+"(getSession method used)</p><br><br><br>");
          pw.println("session id: "+sess.getId());
          pw.println("session getLastAccessedTime"+sess.getLastAccessedTime());
          Enumeration names = sess.getAttributeNames();
          while (names.hasMoreElements()) {
               String name = (String) names.nextElement();
               Object value = sess.getAttribute(name);
               pw.println("<p>name=" + name + " value=" + value+"</p><br>");
         pw.println("<p>Last Name: <input type='text' name='lastname'></p>");
         pw.println("<p><input type='submit' value='Enter'></p>");
//         HttpSession sesslast = req.getSession();
//         sesslast.setAttribute("lastname","lastname");
         pw.println("</form></body></html>");
         pw.close();
FirstandLastNameSessionServlet.java
//FirstandLastNameSessionServlet.java
package myname;
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class FirstandLastNameSessionServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         doPost(req, res);
    public void doPost(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException
         res.setContentType("text/html");
         PrintWriter pw=res.getWriter();
         pw.println("<html><body>");
         HttpSession sess = req.getSession(true);
         String firstname = (String)sess.getAttribute("firstname");
         //String lastname = (String) sess.getAttribute("lastname");
         String lastname = req.getParameter("lastname");
         pw.println("<p>your first name is: "+firstname+"<br>");
         pw.println("your last name is: "+lastname+"</p><br><br><br>");
         Enumeration names = sess.getAttributeNames();
          while (names.hasMoreElements()) {
               String name = (String) names.nextElement();
               Object value = sess.getAttribute(name);
               pw.println("<p>name=" + name + " value=" + value);
          pw.println("session id: "+     sess.getId());
         pw.println("<h1>session tracked success</h1>");
         pw.println("</body></html>");
         pw.close();
}

Your understanding of the flow seems to be a little flawed.
When you first open the FirstNameSessionServlet, you get the textbox asking for the firstname:
>
FirstNameSessionServlet.java
[public void doPost(HttpServletRequest req,
HttpServletResponse res) throws IOException,
ServletException
     res.setContentType("text/html");
     PrintWriter pw=res.getWriter();
     pw.println("<html><body>");
pw.println("<form
m
action='/contentnames/uti/LastNameSessionServletpath'
method='post'>");
pw.println("<p>First Name: <input type='text'
' name = 'firstname'></p>");
pw.println("<p><input type='submit'
' value='Enter'></p>");//The running of the code till this point generates the HTML page, but your servlet is not done yet! Think of it as a function that till now, has printed some output ( the output being HTML code and the destination being the broswer ); but the function has not finished executing yet:
     String firstname= req.getParameter("firstname");
     HttpSession sess = req.getSession(true);
     sess.setAttribute("firstname",firstname);
     // Now, the immediately preceding part of your code creates a string and tries to put the value of the request parameter firstname into it and then put that string into the session object. But guess what? Your application has only just started running, this is your first page and there is no parameter in the request object with this name! This part of the code should come in the next servlet.
     pw.println("</form></body></html>");
     pw.close();
LastNameSessionServlet.java
String firstname=
= req.getParameter("firstname");// This time, req.getParameter() will work since you submitted the last form which had a textbox with this name, you'll get the contents of that box.
     int attrib=1;
     HttpSession sess = req.getSession();
String firstnamesession = (String)
) sess.getAttribute("firstname");//In the last servlet, you put in this parameter, but the value was null for reasons explained above.
     HttpSession sesslast = req.getSession();
     sesslast.setAttribute("lastname","lastname");
     //Again, you will get null for lastname if you tried to access it from the request object since you only just created the field with that name and you would be trying to access it within the same servlet.
     pw.println("</form></body></html>");
     pw.close();
FirstandLastNameSessionServlet.java
     HttpSession sess = req.getSession(true);
String firstname =
= (String)sess.getAttribute("firstname");//this will still not work since you never put a correct value in the session object ( should have done after req.getParameter("firstname") in the second servlet )

Similar Messages

Servlet session tracking without encodeUrl()

Hi,
I'd like use sessions without classic tracking where references are completely encoded by encodeUrl(). I thought about something like "servlet?sessionId=xxx&otherparam=yyyy". Can I do it with compatibility with classic session objects?
Thanks in advance,
Tom

Hi,
I'd like use sessions without classic tracking where references are completely encoded by encodeUrl(). I thought about something like "servlet?sessionId=xxx&otherparam=yyyy". Can I do it with compatibility with classic session objects?
Thanks in advance,
Tom

What is session tracking in servlets?

Hi ,
I'm studying servlets I don't have the clear idea about session tracking and Why and where we need to use it. Can any one say about this.....
Thanks in advance,
Maheshwaran Devaraj

Well Mheshpmr session tracking in servlets is very important...There are a number of problems that arise from the fact that HTTP is a "stateless" protocol. In particular, when you are doing on-line shopping, it is a real annoyance that the Web server can't easily remember previous transactions. This makes applications like shopping carts very problematic: when you add an entry to your cart, how does the server know what's already in your cart? Even if servers did retain contextual information, you'd still have problems with e-commerce. When you move from the page where you specify what you want to buy (hosted on the regular Web server) to the page that takes your credit card number and shipping address (hosted on the secure server that uses SSL), now let me tell you, how does the server remember what you were buying?
Well There are three typical solutions to this problem.
1. Cookies. You can use HTTP cookies to store information about a shopping session, and each subsequent connection can look up the current session and then extract information about that session from some location on the server machine. This is an excellent alternative, and is the most widely used approach. However, even though servlets have a high-level and easy-to-use interface to cookies, there are still a number of relatively tedious details that need to be handled:
* Extracting the cookie that stores the session identifier from the other cookies (there may be many, after all),
* Setting an appropriate expiration time for the cookie (sessions interrupted by 24 hours probably should be reset), and
* Associating information on the server with the session identifier (there may be far too much information to actually store it in the cookie, plus sensitive data like credit card numbers should never go in cookies).
2. URL Rewriting. You can append some extra data on the end of each URL that identifies the session, and the server can associate that session identifier with data it has stored about that session. This is also an excellent solution, and even has the advantage that it works with browsers that don't support cookies or where the user has disabled cookies. However, it has most of the same problems as cookies, namely that the server-side program has a lot of straightforward but tedious processing to do. In addition, you have to be very careful that every URL returned to the user (even via indirect means like Location fields in server redirects) has the extra information appended. And, if the user leaves the session and comes back via a bookmark or link, the session information can be lost.
3. Hidden form fields. HTML forms have an entry that looks like the following: <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">. This means that, when the form is submitted, the specified name and value are included in the GET or POST data. This can be used to store information about the session. However, it has the major disadvantage that it only works if every page is dynamically generated, since the whole point is that each session has a unique identifier.
Servlets provide an outstanding technical solution: the HttpSession API. This is a high-level interface built on top of cookies or URL-rewriting. In fact, on many servers, they use cookies if the browser supports them, but automatically revert to URL-rewriting when cookies are unsupported or explicitly disabled. But the servlet author doesn't need to bother with many of the details, doesn't have to explicitly manipulate cookies or information appended to the URL, and is automatically given a convenient place to store data that is associated with each session.

Session tracking and Internet Explorer

Hi,
I am currently maintaining a servlet application, on apache/jserv.
This application implements a session tracking using a shared static hashtable of session data, associated with session id's.
This application may open more than one client browser windows.
With netscape, no problem.
With Internet Explorer, since the version 6, when the client close at least one window, the session is closed.
Thus, the application reject any new request from this client, sent by still open windows (session cannot be retrieved in the hashtable).
Has somebody heard about this problem ?
Thanks for any answer.

Thanks.
In fact, I believe that IE keeps the same session for
child windows.
The problem is: when you click on a link which open a
new window, the new open window share the session with
its parent window.
When the new window is closed, the session is also
closed.
It appears that this mechanism only exists since the
version 6 of IE.No. Earlier IE version handle session cookies the same way.

Always use URL Rewriting for session tracking?

All you JSP guru:
I am working on a JSP project that requires session tracking. I have successfully implements session tracking with both cookies or URL rewriting. I know that with the HttpSession object, it will always try to use cookie first, if that's disabled, then it'll automatically switch to URL rewriting. However, is there a way to force the HttpSession object to ALWAYS use URL rewriting instead of cookies? I have searched for an answer for a long time and haven't been able to found a solution. Is it possible at all? Thank you very much.

i was going to say that WebSphere always uses URL rewriting if you enable it at all, but someone beat me to it (indirectly) :-)
however, that seemed to me to be a violation of the spec, which seemed to imply the behaviour you're describing (only use URL rewriting if cookies are not supported on the current client)
here's a response someone else made on a websphere newsgroup to a statement in that regard:
I believe you are technically correct. However from my
experience, I think the spec if flawed in this area since
there is no reliable way of determining whether the
client browser supports cookies. The authority on
cookies (www.cookiecentral.com) says:
"To properly detect if a cookie is being accepted via
the server, the cookie needs to be set on one HTTP
request and read back in another. This cannot be
accomplished within 1 request."
This is asking too much of a servlet engine
implementation. Even if it did submit a request for this
purpose, the user could refuse the cookie. So
then technically the browser supports cookies, but the
servlet engine infers it doesn't. So if the servlet engine
infers the browser does not support cookies and so
encodes the URL, it is again out of spec because the
browser really does support cookies. By doing it
however encoding is configured makes things simpler,
robust, consistent and avoids the flaw.
My opinion.so, mostly i'm just rambling, but if you're using websphere, you should get the behaviour your boss wants. if you're using something else, i suppose there's a chance it'll "violate" the spec in this same, potentially helpful way.
btw, i remember somebody else complaining that URL rewriting is less secure than cookies, but i kinda think they're about equal. it seems like either could be intercepted by a sniffer and then used to spoof. but i'm no expert in that stuff...

Oracle Forms Session Tracking mechanism

Hi,
In this doc http://www.oracle.com/technology/products/forms/pdf/10g/troubleshooting_fls.pdf we can read the following:
The JsessionID, which uniquely identifies a Forms session. The Forms Listener Servlet uses two session tracking mechanisms:
- Cookies, where the Servlet container sends a cookie to the client.
The client returns the cookie to the server upon each HTTP
request, thereby associating the session with the cookie.
- URL rewriting, where the Servlet container appends a session ID
to the URL path, for example:
http://host[:port]/forms90/l90servlet;jsessionid=a23445bcde89
Does this means that forms uses one of those, or uses both mechanisms simultaneous?
anyone?
Regards
Ricardo
Edited by: user12015527 on Mar 10, 2010 2:39 PM

duplicate post: Oracle forms session crashes.

Does Tomcat 4.0 support session tracking?

I have use Tomcat 4.0 to run my servlet code with session tracking, however it has no compile error but have error when the servlet is run with the session code..
Anyone know what the probles?

The following are the error message:
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet execution threw an exception
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
     at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:475)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
     at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
     at java.lang.Thread.run(Thread.java:484)
root cause
java.lang.NoSuchMethodError
     at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1185)
     at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191)
     at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191)
     at SessionExample.doGet(SessionExample.java:66)
     at SessionExample.doPost(SessionExample.java:121)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
     at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:475)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
     at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
     at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
     at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
     at java.lang.Thread.run(Thread.java:484)

Tomcat Session Tracking with Object Post and Repeated Applet Jar Download

Hi there,
I have an issue with session tracking in Tomcat (5.0.28) and the JRE repeatedly downloading the original Applet Jar.
Everything works fine (session tracking and HTTP GETs) until I post an Object from the Applet to a Servlet and the Servlet reads the Object.
After that happens the JRE downloads the Applet Jar about 20 times and continues to download it after further requests to the Servlet.
Not sure if the following is related but I'm parsing XML returned by the Servlet in the Applet and I get the following in the Tomcat logs:
127.0.0.1 - - [08/Feb/2005:08:43:12 +0000] "GET /[webapp_path]/servlet/META-INF/services/javax.xml.parsers.SAXParserFactory HTTP/1.1" 404 1142
If I turn off the session tracking in the Servlet it all works fine.
I'm using the standard HTTPSession tracking API.
Any help is much appreciated as this is a serious issue!
Ian

...furthermore...
I've now found I had disabled caching in the JRE.
If I enable it the immediately after a POST (not an Object) then the Applet is repeatedly downloaded and it appears more so than before.

Does Conection Pooling affect my session tracking?

hi
in today's world of growing internet users it's very difficult to handle the number of requests that come at a time.
Considering an example of a website such as a commercial one and i am in a scenario where i track the session of a user
i use a servlet for this purpose..and let's assume that a javawebserver is the server
after a few months my site hits the peak and i am not able to handle so many requests at a time i have a one more javawebserver apart from the existing one and i distribute the requests saying the first 10 to server 1 and the next 10 on server 2
A visitor enters and i start keeping track of the user ..what will happen if the user when made a request
first was directed to the server1 and the same user when makes a second request is on server 2
then will session tracking of a particular user still be possible
In anticipation of a favourable response
Regards

There are a number of ways that you can handle this. For example, ATG's Dynamo application server generates it's own session id and, as part of this session id, it uses a code that specifies which server the session lives on. Then, the load balancing software (which is obviously custom written to look for this code) properly redirects the request "behind the scenes" to the server that this session originated from.
There are other ways to handle this, but the above is the most straightforward IMHO.

URL Session Tracking

Hi,
i want to make a group of JSP pages in a Web App, but assuming that the browser doesn't accept cookies.
Is there anyway that i don't have to indicate every link as
response.encodeUrl("index.jsp")I've heard something about a <url-session-tracking/> tag, but i've tried to put in the web.xml file, but it doesn't work.
I just want to put Index and the App Server takes care of putting the jsessionid info in front of the url
Thank you

Cancelling this question.

Can we use an overloaded constructor of a Java Bean with Session Tracking

Hi Friends,
If any one can solve my query.... It would be helpful.
Query:
I have a Java Bean with an overloaded constructor in it. I want to use the overloaded constructor in my JSP.
1. One way of doing that is to use it directly in the "Scriptlets" (<% %>). But then I am not sure of the way to do session tracking. I think I can use the implicit objects like "session", "request" etc. but not sure of the approach or of the implementation method.
2. Another way is through the directive <jsp: useBean>. But I cannot call an overloaded constructor with <jsp: useBean>. The only alternative way is to use the directive <jsp: useBean> where I have to write getter and setter methods in the Java Bean and use the <jsp: setProperty> and <jsp: getProperty> standard actions. Then with this approach I cannot use the overloaded constructor.
Can any one suggest me the best approach to solve this problem ?
Thanks and Regards,
Gaive.

My first reaction is that you can refactor your overloaded constructor into an init(arguments...) method. Instead of overloaded constructor, you can call that init method. This is the ideal solution if possible.
As to the two choices you listed:
1. This is OK, I believe. You can use scriplet to define the bean and put it into session scope of the pageContext. I am not sure exactly what you meant by session tracking; whatever you meant, it should be doable using HttpSessionAttributeListener and/or HttpSessionBindingListener.
2. Agreed. There is no way that <jsp:useBean> can call a constructor that has non-empty arguments.
Please tell me how it works for you.

How to do session tracking in JSP

I want to do session tracking in my JSP pages.Say once after the user logs in,on every page I can get his username for further use.Thank you for your help!
Richard

<%
session.setAttribute("svUserName", request.getParameter("name_of_username_form_field"));
// from the login page
%>
then to retrieve,
<% String UserName;
UserName = (String)session.getAttribute("svUserName").toString(); %>
to display,
<%= UserName %>

How to use session tracking

i am making shopping mall project .
ist page conatins list of product avaiale
2nd page contains list of manufacturuer avaible
problem:-
i want to display on 3rd page the product seleted by user in 1st page
i used session tracking concept.but problem is the value is coming null in third page
please tell me how to solve my problem

If it is like a shopping cart, I suggest you to look for a good shopping cart examples available plenty online.
But if its just about keeping session variables and using them the following works.
Test with a simple example. Have three jsp files like a.jsp, b.jsp and c.jsp.
put the following in a.jsp
<% session.setAttribute("Mobile","Nokia");%>
<%=session.getAttribute("Mobile")%>
<a href="b.jsp">Go to B.jsp</a>Print the value of session variable - <%=session.getAttribute("Mobile")%> in b.jsp and c.jsp
And in b.jsp have a link to c.jsp and so on. Once you set a session variable, it lives as long as your session doesnt expire.
Try it. and also look for more session tracking examples online.
Message was edited by:
passion_for_java

Session Tracking in Flex

Hi All,
I need a simple session tracking application. this
application should include the following
1) Each user should have a seperate session area where each
user can store some info into it and retrive it.
2) Know how many users have logged into the application.
I come from j2ee background where these things are possible,
so requiring the same for my application which involves multi user
environment.
If not the application some part of code/ ideas will be higly
appreciated.
Thanks in Advance to all,
Vijay Karthik

Hi Avinash,
Put a status variable in the ModelLocator class(If you are using any Model class where your data can be accessed globally through out the application).
Once the user is authenticated and logged in successfuly update the status of the variable and you can authorize based on this status variable whether
the user is authorized to see the pages or not...
Thanks,
Bhasker Chari

Disable non-SSL session tracking?

Hi, all,
I wonder if one can disable all session tracking in JSP's whenever SSL is not being used? I would like to turn off all cookie-setting and URL-rewriting and use SSL-session tracking only (if I use session-tracking at all on a given page). I also want to specify this behavior programmatically (inside my JSP's) and not in my server's config files.
I'm basically concerned that if my user leaves one of my HTTPS pages, they will still retain a non-secure cookie with their session information. This seems to be indeed the default behavior: when I run my tests and transition from an HTTPS page to an HTTP one, the browser does store a cookie. I know I can invalidate the session as the next step, but I'd rather have the cookie not being set altogether to begin with. Imagine the situation where the user leaves my HTTPS page for a totally different (HTTP) website: in this setting I won't get a chance to invalidate the session and delete the cookie.
Any ideas, therefore, on how to programmatically disable non-SSL session-tracking?
Thanks,
Dmitri.

I don't think you can do this programatically.
However I also don't think it is a problem.
Cookies are related to zone names aren't they?
http://mysite and https://mysite are two different
zones as far as cookies are concerned. One should
not be able to see the other.
It issues a new cookie for the http site you are just
navigating to. That cookie has nothing to do with
the secure site you just came from, and shouldn't be
able to tell them any info about the secure site.
I think you are worrying about something that isn't
really there.
What is your concern? That they pick up a JSESSIONID
from the cookie and can then pretend to be a
different user?Yes. A cookie is transmitted and stored unencrypted, I imagine (in any case, it should be more easily crackable than SSL). I wish Sun came up with an extension to the Session API where you would be able to explicitly specify which session-tracking protocols you want used and which ones you don't. At the moment their API abstracts and manages too much detail for you.
I mean, if my site is supposed to be secure while I'm using SSL, then you'd expect that no information about those secure sessions should leak outside the SSL protocol, wouldn't you say?

Servlets: session tracking

Similar Messages

Maybe you are looking for