• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 467
  • Last Modified:

incorrect jsp display problem

I have a legacy app written using STRUTS 1.3 which uses a set of frames to display content. We have a header, footer, left panel, right panel, and a center frame.

The footer has a Save button (among others). When I press Save the form executes the validate() method which checks that the user entered the fields properly. If a field is incorrect (in this case I force the error by leaving one of the dropdowns blank), an error message is added into the header stating which field is wrong.

Pressing Save works fine up to maybe 8 times out of 10 at best, or might fail 2-3 times in a row and then work.

When it works, all the frames get refreshed and the message is displayed in the header.

When it doesn’t work the entire frameset gets displayed/repeated in the center frame with the inner center frame blank/white.    

The center jsp has <html:form action="/LocEndOfficeInfo.do" method="post"> in it. I have tried adding target=”center” or target=”_top” to it but doesn’t make any difference. It just randomly works or doesn’t work. Almost feels like a timing issue with the browser as it renders the frames. I’m using IE8 (only browser this app officially supports) but I also tried Firefox (latest version) and both have the problem.

Also tried calling a javascript function (from the center frame) to reload itself but it then reloads repeatedly without any user input.

Strange thing is that this app has two other center pages which are extremely similar (uses the same header, footer, etc) but never have a problem.

Any ideas on what else I can try?
  • 3
  • 2
  • 2
  • +1
2 Solutions
Two things:

a) First see if there is something in the logs
b) Turn on javascript debugging and see if it fails at some point.
Framesets are a 2oth century technology that has basically disappeared in modern development; and even back in the days if IE8 it was already considered a deadend methodology.  If you post a link to the page we might be able to see what is wrong. If all you ever have to support is IE8, then leaving the legacy code is probably okay, but if you ever have to support modern browsers you may run into multiple issues with it.

Framesets are still very widely used.  They have not disappeared in modern development at all.   They are a part of the HTML standard, and will continue to be, since they solve a problem.

Gandharva_Guy:  it sounds as if there's a problem in your html and possibly your javascript.  If you're seeing a problem with behavior in IE8, you are likely to see even more problems with Chrome.

Without the code, we can't debug the issue.  You can post the code, as other experts have asked, or post the page somewhere where we can see it.
7 new features that'll make your work life better

It’s our mission to create a product that solves the huge challenges you face at work every day. In case you missed it, here are 7 delightful things we've added recently to monday to make it even more awesome.

Framesets are still very widely used.

I don't know where you come up with that.  Your source of stats would be interesting.

Current usage is 1.8%. I get my stats from:

Modern sites do not use frames, though iframes are relatively common primarily for offsite content like video and connections to social networking APIs.

As for support, frameset is not part of the HTML5 standard, having been dropped along with other obsolete attributes like font.  The browsers still recognize the obsolete bits for backward compatibility, but the manufacturers can drop support anytime they want and still be standards compliant.

Gandharva_GuyAuthor Commented:
Logs show nothing unfortunately.
I did use Fiddler (a debugging tool) and it clearly shows that 10 jsps are returned when it fails, and 6 when it works. So now I'm not really sure if the problem lies with the jsp below or something else since it works intermittently.

Here's a snip of the jsp which comes up blank. Note that I removed the content (which is some tables, dropdowns etc) for simplicity.

<%@ page language="java" extends="ca.ncams.wisor.filter.FilterJspBase" 
<%@ page import="ca.ncams.wisor.presentation.tables.LocEndOfficeInfoForm" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<%@ taglib prefix="html" uri="/WEB-INF/struts-html.tld" %>

<html:html >
<link rel=stylesheet type="text/css" href="../contentstyles.css" title="Content Style">
<jsp:include page="/javascript/mainSubmit.js" flush="true" />
<jsp:include page="/javascript/auto.js" />

<body bgcolor="#F5F5DC">
<html:form action="/LocEndOfficeInfo.do" method="post"> 
<html:hidden property="action"/>

<!-- content removed for simplicity -->


Open in new window

Weird -- do you have 10 or 6 frames?  I don't see why you would get 10 or 6 files returned from the server.

Using fiddler to watch the actual files returned is an excellent start.

However, if you don't have enough logging to determine the problem on the server, I don't think we can help you until you have more information to work with.

We can recommend tools.  Fiddler is a good start.  You should also look at your code to see why 10 .jsp files are returned, and why 6 is ... better? worse?  Are you using individual .jsp files as the returned html for each frame in an html page?

So many things can cause different files returned to a browser.  A short list:
* different browser
* diff user OS
* diff user login
* different browser settings
* different parameters in the query to the server
* different requests to the server
* different states in the server in the responses
* badly written code on the server which ... does not close db connections, is not threadsafe, relies on shared data when it shouldn't and the data isn't shared, ... the list here is endless
* poorly understood server configuration.  If you are load-balancing among several web servers, one (or more) of them could be wronly configured, and returning the unexpected files

The best bet was for you to look in your webapp logs and determine what was different in the 2 cases.  You should add logging to your app so that you can start tracking down the problem.  It's harder to do by code inspection.

If you cannot debug the code on the server, you can go the longer way and get more info from the client side.  Using something like a network monitor -- Windows has one, or you can install an open source one like Ethereal or Wireshark -- will show you a lot of detail about the behavior the client sees in requests to the server and responses from the server.

In any case, you'll need to continue to do a lot more investigation and post what you've found here to get further.

Ignore the "nobody uses framesets" discussion -- it's completely irrelevant to your question.
Gandharva_GuyAuthor Commented:
Ok, update. Turns out it was a code issue on the server side that was telling STRUTS to go to the wrong jsp (even though it looked correct). We compared with an older version of the java class that caused the problem and were able to come up with a fix that solves it for the majority of cases...there's still one or two other unusual/uncommon cases that have the problem but I gather it's the same type of issue. If push comes to shove we'll probably try upgrading from STRUTS 1.3 to the latest release (which would require some architecture changes) but I think we'll be able to live with it as it is now.

Thanks all for your input!  

ps. I do hope to upgrade this app to use a much more modern framework to get rid of framesets someday! GWT is looking pretty good to me.
Gandharva_GuyAuthor Commented:
Found my own solution but all the feedback was still useful.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now