Develop Reference

Session Timeout/Expiry in java

Is it advisable to set
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
what are the dis advantages of doing so ??? Is there any better way to make sure the session never expires ???

There are no disadvantages. That just means the session won't expire. How would there be a "better" way?

XML Attribute lookup via java bean

I've web.xml where tomcat lookup for value
<session-config>
<session-timeout>30</session-timeout>
</session-config>
I want the same value to be fetched into javabean file as variable.
Is there any better way to lookup on this without actually pasing throuh entire xml file to get just a value.
Does this can be implemented by JNDI lookup ?
Again, TY for your help.

One way I think you can do it(though verbose) is to implement your own HttpSessionListener. Override its sessionCreated() method, you can get a reference to the HttpSession from the HttpSessionEvent and by invoking HttpSession#getMaxInactiveInterval(), you can get the session-timeout value in seconds. You can then store the value in your bean. there will be cons to this solutions, I will update it.

SessionTimeout: web.xml vs session.maxInactiveInterval()

I'm trying to timeout an HttpSession in Java. My container is WebLogic.
Currently, we have our session timeout set in the web.xml file, like this
<session-config>
<session-timeout>15</session-timeout>
</session-config>
Now, I'm being told that this will terminate the session (or is it all sessions?) in the 15th minute of use, regardless their activity.
I'm wondering if this approach is the correct one, or should I programatically set the time limit of inactivity by
session.setMaxInactiveInterval(15 * 60); //15 minutes
I don't want to drop all sessions at 15 minutes, only those that have been inactive for 15 minutes.
Are these methods equivalent? Should I favour the web.xml config?

Now, i'm being told that this will terminate the session (or is it all sessions?) in the 15th minute of use, regardless their activity.
This is wrong. It will just kill the session when the associated client (webbrowser) has not accessed the website for more than 15 minutes. The activity certainly counts, exactly as you initially expected, seeing your attempt to solve this.
The HttpSession#setMaxInactiveInterval() doesn't change much here by the way. It does exactly the same as <session-timeout> in web.xml, with the only difference that you can change/set it programmatically during runtime. The change by the way only affects the current session instance, not globally (else it would have been a static method).
To play around and experience this yourself, try to set <session-timeout> to 1 minute and create a HttpSessionListener like follows:
#WebListener
public class HttpSessionChecker implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent event) {
System.out.printf("Session ID %s created at %s%n", event.getSession().getId(), new Date());
}
public void sessionDestroyed(HttpSessionEvent event) {
System.out.printf("Session ID %s destroyed at %s%n", event.getSession().getId(), new Date());
}
}
(if you're not on Servlet 3.0 yet and thus can't use #WebListener, then register in web.xml as follows):
<listener>
<listener-class>com.example.HttpSessionChecker</listener-class>
</listener>
Note that the servletcontainer won't immediately destroy sessions after exactly the timeout value. It's a background job which runs at certain intervals (e.g. 5~15 minutes depending on load and the servletcontainer make/type). So don't be surprised when you don't see destroyed line in the console immediately after exactly one minute of inactivity. However, when you fire a HTTP request on a timed-out-but-not-destroyed-yet session, it will be destroyed immediately.
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading

Now, i'm being told that this will terminate the session (or is it all sessions?) in the 15th minute of use, regardless their activity.
No, that's not true. The session-timeout configures a per session timeout in case of inactivity.
Are these methods equivalent? Should I favour the web.xml config?
The setting in the web.xml is global, it applies to all sessions of a given context. Programatically, you can change this for a particular session.

Session-timeout configuration doesn't work?

In web.xml I have this
<session-config>
<session-timeout>2</session-timeout>
</session-config>
<listener>
<listener-class>myapplication.SessionListener</listener-class>
</listener>
In the SessionListener.java I have
public void sessionDestroyed (HttpSessionEvent event){
System.out.println("Visitor Removed!!");
}
But it seems System.out.println("Visitor Removed!!") has never been executed. I am new to Tomcat 6 and JSP. Any suggestion please?

This can have at least 3 causes:
The session has never been created. Listen on sessionCreated() as well.
You are a bit impatient. Session destroy happens lazily and at intervals. It does not happen immediately. If you fire a new request in the same session while it has been expired, then sessionDestroyed() will be called. Or if you have a bit more patience, the server will run its low-prio timer job to reap all expired sessions.
You are not using the myapplication.SessionListener class in the classpath as you think you're using, maybe the one actually in the classpath doesn't have a sysout line.

how to catch and throw errors in JSP

I asked a question along similar lines yesterday as well. In that question I was suggested to have a global filter (which I already had).
So I have a JSP like below
....code...code
..tags...html...code
Object [] res = iBatisDAO.getReport_pging(null,null,0,null); //call to DB
...more code...
...tags...end
In the above code I am intentionally passing null's because I want it to fail and when it fails I want it to go to our centralized error page. I have the following in my web.xml
<error-page>
<exception-type>com.ibatis.common.jdbc.exception.NestedSQLException</exception-type>
<location>/errorpages/Error.jsp</location>
</error-page>
<error-page>
<exception-type>org.springframework.dao.DataAccessException</exception-type>
<location>/errorpages/Error.jsp</location>
</error-page>
<error-page>
<exception-type>javax.servlet.ServletException</exception-type>
<location>/errorpages/Error.jsp</location>
</error-page>
<error-page>
<exception-type>java.sql.SQLException</exception-type>
<location>/errorpages/Error.jsp</location>
</error-page>
<error-page>
<exception-type>org.springframework.jdbc.UncategorizedSQLException</exception-type>
<location>/errorpages/Error.jsp</location>
</error-page>
the 'control' comes to the above JSP via a global filter that I have. it has chain.doFilter() wrapped in try/catch block. When exception happens it redirects to Error.jsp.
When the error happens...it is not being caught by the centralized error page and neither is it caught by the filter. I think filter is not catching it because when filter 'calls' the jsp...there IS no error yet.
I know call to DB is BAD inside a JSP but I am dealing with lot of legacy code.
What can I do to have errors go to centralized error page in this scenario? Also, the JSP does not have the error page imported. I would not want the option of importing an error page to all JSP's I want to have a more general solution.

Exceptions in JSP cannot be handled nicely, because it's too late to change the response. JSP as being a view technology is responsible for the whole response at its own. It sends the response headers and the response content. When the response headers are sent, then it's a point of no return. Even a filter ain't going to help here.
Whenever an exception occurs halfway a JSP, then the response will be abruptly aborted and the client will face a blank or a halfbaked page and the exception can at highest only be logged to the server log. Maybe along an IllegalStateException: response already committed whenever an attempt is made to redirect/forward/display the error page while that's impossible, because the response is already committed.
In short: do not write raw Java code in JSP files. Put them in Java classes such as (in)direct in a Servlet. It get processed before the JSP get displayed. This way there's plenty of room to change the destination of the response.
If you insist in using JSP for business logic (which I do not recommend), then an alternative is to put all the business logic to the top of the JSP file, before any template text (HTML and so on) is to be sent to the response. If you're lucky, the servletcontainer will be able to change the response to an error page whenever an exception is been thrown.

You've undertaken a wrong approach. You must not have any logic processing code (business logic) in your JSP files. JSP is a view technology. Use servlets or some action/component framework (Struts2 / Spring MVC / JSF / etc.) to handle the business logic.
As for the filter approach - it is a good solution, but the filter must be mapped to /* (using <filter-mapping>):
<filter>
<filter-name>exceptionFilter</filter-name>
<filter-class>com.yourpackage.YourFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>exceptionFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>