Alan Shiers

DataTables v1.10.0 has recently been released and in response Tactical Enterprises Ltd has released JED v1.1 to support DataTables and Editor on the server side on the Java platform. The transition from DataTables v1.9 to v1.10 has seen a change in the way parameters are passed to and from the server side and the naming of properties conforming to camelCase notation. JED version 1.1 addresses these changes. If you are looking for a fully editable table interface for your next web application project, go to the JED Website.

Often required for many Web Applications is the desire to display tabular data in a dynamic table in web pages. For some time now, SpryMedia came out with DataTables which does the trick, however, it did not support the Java Platform. It was written for the PHP platform. Miracles do happen though and Tactical Enterprises Ltd has recently released JED (Java Editor For DataTables).

Now we're getting somewhere! You can now use DataTables on the client side, along with JED for the backend to communicate with MySQL or Oracle databases. You can perform CRUD (Create,Read,Update and Delete) operations in your webpages with DataTables just as you could in a standalone application using SWING.

If you've been waiting for this kind of widget for your web applications, you don't need to wait any longer. CHECK IT OUT: http://jed-datatables.ca/jed/

Thanks for the input guys. Getting your perspectives on the problem certainly helps. Gregg, I wasn't aware of the Quartz library and found it quite interesting. It may come in handy for a future project, but I think Bear is on a better track. For this particular project I'll just refuse to honor the process if they're too late, and return a message that states they need to begin again from the start.

Alan

Hi there,

I'm working on a web app that involves a login procedure. More specifically, the procedure for resetting forgotten passwords. When a user goes to the Login.jsp page and has forgotten their password, they can click on the link that is labelled "Forgot Password?". When they click on the link, they are sent to another page where they enter their email address and click submit. The email address is sent via POST to a servlet that finds the record in the database that coincides with the email address and sets a TimeStamp field and another field that will contain a special String token. The servlet also sends an email to the user with instructions.

An additional thing I wanted the servlet to do is initialize a new Thread that performs a check in one hour by sending the following UPDATE query to the database:

UPDATE users SET pwd_reset_timestamp=null, pwd_special_token=null WHERE users.uid = 7 AND TIMESTAMPDIFF(MINUTE,pwd_reset_timestamp,NOW()) > 60;

The instructions sent to the user stipulate that they have one hour to return to the website and reset their password. If they fail to do so, the Thread will reset the timestamp and token fields back to null.

That is how I originally envisioned the procedure. But I'm wondering if creating a new Thread inside a servlet is a wise thing to do? Once the Servlet has completed, will the Thread still be alive to do its job in one hour? Is there a better mechanism available that can perform the task within the time frame specified?

Please advise,

Alan

OK...I finally found something that actually works! After much research on the internet, I wound up creating a filter class:

import java.io.IOException; import javax.servlet.Filter; import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletResponse; public class NoCacheFilter implements Filter { public void init(FilterConfig config) throws ServletException { // If you have any <init-param> in web.xml, then you could get them // here by config.getInitParameter("name") and assign it as field. } @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse hsr = (HttpServletResponse) res; hsr.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1. hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0. hsr.setDateHeader("Expires", 0); // Proxies. chain.doFilter(req, res); } @Override public void destroy() { // If you have assigned any expensive resources as field of // this Filter class, then you could clean/close them here. } }

I added the following to the web.xml file:

<filter-name>noCacheFilter</filter-name>
<filter-class>com.tacticalenterprisesltd.NoCacheFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>noCacheFilter</filter-name>
<url-pattern>/search/*</url-pattern>
</filter-mapping>

On all my JSP files I removed all META tags and response Headers regarding cache. I cleared all browsers of cached files, restarted Tomcat, reopened the browsers and ran the test. Finally, the browsers aren't caching. I still don't know why they were still caching prior to the implementation of the filter class, but they were despite the fact that the instructions were there on every JSP page. I'm just thankful I found something that works. Thanks for all your advise guys.

Alan

Ulf Dittmer wrote:I see, sorry, I missed that. And this page is reached via a POST? And you can still just click the back button and get back to it?

The servlets LoginServlet and LogoutServlet are reached via POST, yes. What's happening, that I can see, is that even though I set the headers and META tags to stop the browsers from caching, they're doing it anyway. When I test, I first clear the browsers of their cache, close them down, relaunch them and run the test again. That Back button is a real pain in the $%^&*, if you know what I mean.

My login.jsp page has some jquery in it that contacts the LoginServlet which looks like this:

$('#login').click(function(){ var name = $('#uname').val(); var pwd = $('#upassword').val(); if(name == "") { alert("You must provide a user name."); return; } if(pwd == "") { alert("You must provide a password."); return; } $.post('../LoginServlet', {uname:name,upassword:pwd}, function(data) { if(data == "No Match") { alert("There is no match for the combination\nusername and password provided.\nPlease try again."); } else { window.location.href = "csa.jsp"; } }); }); });

Likewise, my csa.jsp page has a similar jquery function for the logout menu:

$('a#logout').click(function(){ $.post('../LogoutServlet'); window.location.href = "../index.jsp"; });

I don't know if any of this helps or not, but there it is.

Ulf Dittmer wrote:Not at all - there is no redirect.

I just showed you the redirect:

if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

From what I've seen about the RPG thing, is that I've been doing that all along. I've pointed out twice now that I do a check on the csa.jsp page for the presence of the attribute "currentSessionUser". The LogoutServlet removes this attribute, plus I've added the line session.invalidate() after I've removed the attribute. csa.jsp now looks like this:

<% UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser"))); ArrayList<Profile> profiles = new ArrayList<Profile>(); //Prevent people from having direct access to this page. if(currentUser == null) { response.sendRedirect("../index.jsp"); } else { int userid = currentUser.getUid(); Database db = new Database("search_assistant"); String query = "SELECT id, name FROM profiles WHERE uid=" + userid; String[][] results = db.executeSelect(query,2); if(results != null) { int length = results.length; Profile p = null; for(int i = 0; i < length; i++) { p = new Profile(); for(int j = 0; j < 2; j++) { if(j == 0) p.setId(Integer.parseInt(results[i][j])); else if(j == 1) p.setName(results[i][j]); } profiles.add(p); } } response.setHeader( "Pragma", "no-cache" ); response.setHeader( "Cache-Control", "no-cache" ); response.setDateHeader( "Expires", 0 ); %> <!doctype html> <html lang="en"> <head> <meta charset="utf-8" /> <meta http-equiv="cache-control" content="max-age=0" /> <meta http-equiv="cache-control" content="no-cache" /> <meta http-equiv="expires" content="0" /> <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" /> <meta http-equiv="pragma" content="no-cache" /> <title>...</title> ...

To me, that is the RPG pattern, isn't it?

Alan

Well, in my JSP pages I have now both the META tags and the response headers set:

response.setHeader( "Pragma", "no-cache" );
response.setHeader( "Cache-Control", "no-cache" );
response.setDateHeader( "Expires", 0 );

Still, when I use the Back button on the browsers I'm able to return to the JSP page. I know it's not suppose to happen, but it does. Any other suggestions?

Alan

OK. I still have an issue with this. Here is what I've done so far:

1. I fixed up the servlets getting rid of the doGet() methods and recompiled.
2. For both browsers IE and FireFox I've cleared out all cache.
3. In all JSP files that I don't want to cache I added the META tags as recommended

When I retest the sequence (logging in, and being presented with the JSP page named csa.jsp, then logging out and returned to home page index.jsp) I can still click the back button and return to the JSP page csa.jsp that tests for the presence of the Session attribute "currentSessionUser".

<%
UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser")));

//Prevent people from having direct access to this page.
if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

...
%>

By rights, currentUser should be null! This csa.jsp page does have the META tags mentioned earlier, therefore this page should not be cached.

Am I missing something?

Also, I'm seeing comments, actually warnings, against the use of Scriptlets. What's up with that? I haven't been living under a rock or anything and this is the first time seeing these types of comments. Did someone discover a major flaw with Scriptlets or something? What's wrong with them?

Alan

Hi there,

I'm working on a web app that involves a Login procedure. When the user fills out a form consisting of username and password, the form data goes to a servlet that sets an attribute in the Session object. So far, so good.

For the logout mechanism, I've created another servlet that simply grabs the Session object and removes the attribute. When the user clicks on the logout menu item, a jquery function calls LogoutServlet, which does its thing, then the user is redirected back to the home page. All this works except...
now on the home page, if I click on the back button on the browser, I'm returned to the previous page. That shouldn't happen. At the top of my JSP page I run a test like so:

UserBean currentUser=((UserBean)(session.getAttribute("currentSessionUser")));

//Prevent people from having direct access to this page.
if(currentUser == null)
{
response.sendRedirect("../index.jsp");
}

Since I removed the attribute "currentSessionUser" from the Session object when I logged out, the variable currentUser should now be null. For some reason, it isn't since I'm able to click the back button on the browser and return to the JSP page without any problem. The logout mechanism isn't working as I had hoped.
Please advise.

Alan

public class LoginServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { doPost(request,response); } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try{ UserBean user=new UserBean(); user.setUsername(request.getParameter("uname")); user.setPassword(request.getParameter("upassword")); user=UserDAO.login(user); if(user.isValid()){ HttpSession session=request.getSession(true); session.setAttribute("currentSessionUser", user); //response.sendRedirect("search/csa.jsp"); } else{ //response.sendRedirect("index.jsp"); response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.print("No Match"); } } catch(Throwable theException){ theException.printStackTrace(); } } } public class LogoutServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { doPost(request,response); } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session=request.getSession(); session.removeAttribute("currentSessionUser"); System.out.println("removed user"); } }

Thanks for the responses fellas. I was able to work it out.

Alan

Hi there,

I've downloaded JForum and trying to get familiar working the configurations. The address field of my browser is defaulting to the Tomcat favicon icon and I want to change it. Is it possible to change it?

Alan

You may want to consider making use of a recently released library of classes supporting the Java Platform for DataTables. If you are looking for CRUD (Create,Read,Update,and Delete) functionality on the server side for the Java platform, JED has just been released. Check it out: http://jed-datatables.ca . You can create whatever tables in your database and JED will retrieve them for you and send the appropriate JSON string to the client side. JED has all the same functionality as the original PHP Editor.

Hi,

Is there anyone here who has had experience with Parellels Plesk Panel on a VPS (Virtual Private Server) and configuring Tomcat with it? I've recently opened an account with GoDaddy and I have a VPS. Parellels Plesk Panel is installed and I've used it to install Tomcat 7.0. So far so good. Unfortunately the tech staff at GoDaddy don't know much of anything about how to configure Tomcat to run Java Web Applications. I need to find a step by step guide on how to upload a WAR file (and into which directory) in this version of Plesk 11.5 and run the web application within it. GoDaddy tech support were able to provide a link to an outdated instruction page, but the instructions don't apply anymore ( http://download1.parallels.com/Plesk/Plesk8.4/Doc/en-US/plesk-8.4-win-administrators-guide/24883.htm). The labels of buttons and links in Plesk have changed considerably. Has anyone out there worked with this version of Plesk 11.5? Please advise.

Alan