We Keep Coding

what method is used by httpSession for session management in Java

I read lot of articles which says that there are different ways to manage the session like cookies, hidden form fields, url rewriting and jsessionId.
But when I do
HttpSession session = request.getSession();
Which method is actually used internally?

According to the servlet 2.4 specification:
Session tracking through HTTP cookies is the most used session
tracking mechanism and is required to be supported by all servlet
containers... To fulfill this requirement, Web containers commonly
support the URL rewriting mechanism.

Basically the session tracking (i.e. to keep the user interaction and sending the data ) can be maintained by 4 ways like HttpSession,cookies,hidden field and URL rewriting.
It depends on your requirement , which it needs to use.
If you are using HttpSession then you need to go for
HttpSession session = request.getSession(true);
As Cookies are client side.
Hidden fields are the form data you need to send to by request to servlet.
URL rewriting is used for sending the data using href or any link (usally GET method).
Session is used for secure and state full transaction.
Which method is actually used internally?
Its recommended to use HttpSession , if you want to track the request data over the application, until unless you invalidate that session. Jsessionid is a part of HttpSession. Internally Session is using unique Jsessionid for each session you are creating.
Hope it will help you.

The answer is that it doesn't depend on Java. It depends on the specific servlet container you are using and possibly the browser as well. If the brower won't accept cookies for example the container may be forced back to using URL rewriting.

In how many ways we can track the sessions in servlet?

What are the different ways to track the session in servlet. Is it is possible by using hidden files ?

There are three ways
hidden form fields
cookies
url encoding.
One of the ways is to use HttpSession You can create session using
HttpSession session = request.getSession();
or you can use HttpSession session = request.getSession(true). Both statements mean that If there is associated session with this user, then return that one or create a new session. If false is passed, then new session is not created.

sessions can be maintained in the following ways
hidden form field.
cookies
encodeURL
session object
have a look at here link

The different ways to track session in servlet are:
Using the session API:
a sample code for that is:
//store the username object in the session-scope
HttpSession session = request.getSession();
session.setAttribute("username",username);
To retrieve the session attribute,use the session.getAttribute()
Username username = (Username) session.getAttribute("username");
Using the cookies API:
sample code:
String name = request.getParameter("username");
Cookie c = new Cookie("username",name);
response.addCookie(c);
It should be noted that a major disadvantage of using cookies for session management is that sometimes the client might have cookies turned off.
Using URL-Rewriting:
The URL-rewriting strategy is not as transparrent as the cookie strategy.
It could be implemented in a form as below:
//present the form
out.println("<form action='"+response.encodeURL("login.")+"'");
Hidden form field can also be used.

Yes,it is possible with hidden fields.
And there are other ways too
User authorization
Hidden fields
URL rewriting
Cookies
Session tracking API

These are the ways to tracking Session
1.With cookies
2.With URL rewriting
3.With SSL information
For more details click here

Session can be maintained in flowing ways
Hidden form field :- Use full when the form are generated dynamically
cookies
URL rewriting
HttpSession
The HttpSession depend on the cookies. It uses cookies to store the session id in client system.

Suppose a servlet that implements HTTP sessions receives HTTP requests from three different clients (browsers). For each client request, the servlet must be able to determine the HTTP session to which the client request pertains. Each client request belongs to just one of the three client sessions being tracked by the servlet. Currently, the product offers three ways to track sessions:
With cookies
With URL rewriting
With SSL information

There are various session tracking mechanisms
Session API
Cookies
URL Rewriting
Hidden Form Fields
Hidden Form Fields ->
In this case, we use hidden text-field for maintaining the state of a user.
It is just programmer's trick to remember client information.

HttpConnection maintaining Session

I'm consuming some web services done in java using a Rest architecture, my client it's a mobile application that uses HttpConnection to retrieve the data. In order to control authentication and authorization I'm using cookies, managed by a #SessionScoped class, however I don't know how to make the session persist through requests. The problem basically is that I inject the Session manager in other services that are #RequestScoped, however since the session is not persisted I always retrieve differente instances for the #SessionScoped class, thus deleting all the cookies or records I had before. Looking at the request headers I noticed the cookie JSESSIONID, I think this is sent by tomcat in order to persist session, so tried already to send the same cookie in the next request, however I got no results.

The comments were right... to persist a session you just have to send the JSESSIONID cookie back to server in the next request, the problem in this case was that HttpConnection in JavaME only has the setRequestProperty method to include a header value, now if you set the same value two times it overwrites the last one. Since I was using a custom cookie and the JSessionID cookie, I setted them in the following way:
connection.setRequestProperty("Cookie","sessionId="+ApplicationPreferences.getIn‌​stance().getSessionCookieHeader());
connection.setRequestProperty("Cookie","JSESSIONID="+ApplicationPreferences‌​.getInstance().getJavaSessionCookieHeader());
When the correct way to do it is concatenate the cookie strings and then setting a Cookie header with them all:
String myCookies="sessionId="+ApplicationPreferences.getInstance().getSessionCookieHead‌​er()+";"+"JSESSIONID="+ApplicationPreferences.getInstance().getJavaSessionCookieHeade‌​r();

Generating Own Session Id in JSF

I have a web application in which we use JSF framework.
I have been diving deep into the security part for web application and hence I was looking to generate my own unique session ID(using encryption algorithm and assign it to every new session which gets created once user logs in.
Can anyone please guide me on how to set manual generated session id in session and ensure with each request that session id is transmitted.
Thanks.

I really doubt you'll generate session IDs that are more secure than the ones generated by the container, but here's what you could do, without using any container-specific extension.
Create a servlet filter which intercept every request to the server.
When a request comes in, check if a session already exists for this request (using getSession(false)). If one exists, then extract your specific cookie MY_SESSION_ID from the request, and compare its value to the one that is stored in the session. If they don't match, reject the request.
If the session doesn't exist, then create it (using getSession(true)), generate your super-secure session ID, store it as a session attribute and add the cookie MY_SESSION_ID to the response.
This has the disadvantage of creating a session automatically, even if it's not strictly needed. But that's the case most of the time when using JSPs of component frameworks.

Attempting to do this at the JSF application layer is unlikely to be successful; I would perform this task at a lower level API. I am assuming a servlet container.
I can think of two approaches:
do this at a container level via a server-specific SPI (if one even exists)
do this by rewriting requests/responses via a servlet Filter
There is insufficient information to comment on the viability of the first approach.
In the second, you would have to determine the name of the session cookie (it is usually JSESSIONID, but does not have to be). Your API would:
map the filter to all application requests
maintain a map of container session ids to "secure" ids
use the filter to rewrite any session cookie in the request with the session id
use the filter rewrite any session cookie in the response with the secure id
use a listener to remove invalid sessions from the map to avoid memory leaks

A new HttpSession for each request?

I've always taken for granted the JSESSIONID cookie created for every fresh request for a given client when developing applications using the servlet specification. But after giving it a bit of thought, isn't is more logical for the servlet container to create a cookie header only after the session has been requested and created in code? For clients who have their cookies disabled, won't it end up creating a new HttpSession for each request made?
Please let me know if the question is still unclear so I can edit it. TIA.

A new Session will not be created by the Servlet container by default unless the Servlet actually creates it explicitly. Just because in the Header a JSEESIONID is being populated does not mean that there has to be a seesion on the server. An exception to this is in JSPs that by default create a Session if one is not there unless <%# page session="false" %>
As far as not having cookies turned on:
A web container can use several
methods to associate a session with a
user, all of which involve passing an
identifier between the client and the
server. The identifier can be
maintained on the client as a cookie,
or the web component can include the
identifier in every URL that is
returned to the client.
If your application uses session
objects, you must ensure that session
tracking is enabled by having the
application rewrite URLs whenever the
client turns off cookies. You do this
by calling the response's
encodeURL(URL) method on all URLs
returned by a servlet. This method
includes the session ID in the URL
only if cookies are disabled;
otherwise, it returns the URL
unchanged.