Tutorials and What's HOT

The most productive way of developing a servlet/JSP app is to structure your app to comply with the Servlet specification. This means creating a WEB-INF directory under your app directory, adding all JAR's to WEB-INF/lib and instructing Eclipse/NetBeans to compile Java sources to WEB-INF/classes. This way, as long as Tomcat's Context reloadable setting is set to true, your app will be reloaded automatically whenever a Java class is updated. No need to rebuild the project and restart Tomcat.

Unfortunately, you are not always free to structure your app. For instance, if your team is using Maven, chances are you will be working with a Maven directory structure. You'll probably have a structure like this:

The codes in this blog are borrowed from my book "Servlet & JSP: A Tutorial, 2nd Edition" (ISBN 9781771970273)

There are many reasons why you would want the browser to know when the HttpSession has expired. First, there are many pages and resources that can only be accessed by authenticated users. When a user’s HttpSession expires, also gone is the user’s proof he’s been authenticated, which is commonly stored in the HttpSession. Controlling access to these resources after the HttpSession expired proves difficult, especially in the era of AJAX programming where resources are often accessed without the user explicitly initiating it.

The second reason why you would want the browser to be notified when the HttpSession expires is to protect resources that are to be consumed by authorized eyes only. If the browser can be notified when such an important event occurs, it can be instructed to forward to a new page or delete the content of its HTML body.

This problem is hard to crack since you cannot send an HTTP request to the server to check if the HttpSession has expired, because doing so will prolong the life of the HttpSession. One common solution is to create a timer on the browser side that gets reset every time the browser makes an attempt to connect the server. This solution works but can be difficult to write.

The following example (in project websocket-config) shows how WebSocket can be used to solve this very old problem in web programming. This example works by persuading the browser to open a WebSocket connection to the server. The connect request is intercepted and the WebSocket Session is added as an attribute to the HttpSession. When the HttpSession expires, the WebSocket Session is retrieved and used to send a message to the browser. To get notified when the HttpSession is about to be destroyed, you need to write an HttpSessionListener and implement its sessionDestroyed method. This method is called right before the HttpSession is invalidated.

The main component of this application is the HttpSessionConfigurator class in Listing 21.8. The modifyHandshake method of this class retrieves the HttpSession object and puts it in the user properties map.

The endpoint in Listing 21.9 is used to link the WebSocket Session with the HttpSession. Note that the @ServerEndpoint annotation has a configurator attribute that is assigned the configurator class in Listing 21.8.

Next is the ExpiryTrackerHttpSessionListener class in Listing 21.10. Its contextDestroyed method gets called before an HttpSession is about to be invalidated. The method also receives the HttpSession. The method retrieves the WebSocket Session and uses it to send a message to the browser.

Finally, the JSP page in Listing 21.11 is an example page that opens a WebSocket connection. If the HttpSession expires when the browser is showing this page, the server sends a message via the WebSocket and the browser gets redirected to a login page.

Every good Java programmer knows that String objects are immutable and a String concatenation always creates a new String and is therefore an expensive operation that should be avoided. In other words, code like this is a taboo:

String s = "Hello";
s += ", World";

Or, is it?

For years, we've been advised to use StringBuilder instead, but today's Java compilers are more intelligent than ever. The Oracle Java compiler (and probably others) will convert the code above to something like this:

How do you prove this? If you have Eclipse installed on your computer, simply create a test class and double-click the .class file in the Navigator view. The disassembled bytecode would look like this:

So, should you start concatenating Strings because it's shorter than using StringBuilder? It depends. If every member in your team knows that compilers are smart, then yes. If not, your manager might think you don't even know the basic rule of working with Strings. Who says this will not cause a delay of your promotion?