Elie Hirschman

Resurrecting this to share:
I combined simple techniques found here: http://rgagnon.com/javadetails/java-0586.html
and here: http://www.theserverside.com/discussions/thread.tss?thread_id=36310

1. Table data
Table data gets dynamically generated, and I surround it with a div tag:
<div id="tableData"> <table border="1"><tr> <th>SKU </th> <th>Highest total</th> <th>Second Highest total</th></tr> <tr><td>Data 1</td><td>Data 2</td><td>Data 3</td></tr> <tr><td>Data 121</td><td>Data 22</td><td>Data 33</td></tr> </table>

2. Export button
on the page with my TABLE data, I add the following HTML:
<form action="excel.jsp"> <input type="hidden" id="tableHTML" name="tableHTML" value="" /> <input type="hidden" id="fileName" name="fileName" value="<%= exportFileName%>" /> <input type="submit" onclick="gotoExcel('tableData', 'tableHTML');" value="Export these results" /> </form>

3. Export Script
add this JS on top:
<script type="text/javascript"> function gotoExcel(elemId, frmFldId) { var obj = document.getElementById(elemId); var oFld = document.getElementById(frmFldId); oFld.value = obj.innerHTML; } </script>

3. The JSP Export page
This new page excel.jsp does all the work:
<%@ page import="java.io.PrintWriter" %> <%@ page contentType="application/excel" language="java" %> <% response.reset(); response.setHeader("Content-type","application/xls"); String fileName = request.getParameter("fileName"); response.setHeader("Content-disposition","inline; filename=" + fileName); PrintWriter op = response.getWriter(); String CSV = request.getParameter("tableHTML"); if (CSV == null) { CSV="NO DATA"; } if (fileName == null) { CSV="NO FILE NAME SPECIFIED"; } op.write(CSV); %>

Tim Holloway wrote:Java versions 6.0.10 and earlier had a known problem when handing off from one applet to another. It drove CPU utilization up to 100%.

Some people claimed problems with 6.0.10 as well, but for me the problem magically disappeared at that point.

Some of my users are using JRE 1.6.0_6, but most are using 1.6.0_15-b03. I personally have the latest and greatest and was still having the issue.
The other thing is, Page X was just a simple JSP with NO applets on it. So it was an applet doing a showDocument on a page with no applets, and returning to a page WITH applets that was causing the locking - still not understanding why.


(BTW, I almost wrote "SITH applets" above... how cool would those applets be!!)

I found a work-around which I will use (for now) - I am using the showDocument() call not to navigate to another page, but to fire a javascript popup modal window, as so:

line from the Java applet:
context.showDocument(new URL("javascript:doPostAppletWork(\"" + url + "\")"));

this calls the Javascript function on the jsp:
function doPostAppletWork(url) { showModal(url,600,400); }

...where showModal is a proprietary function to launch a new modal window with the provided url and window dimensions.

Still wondering why I was experiencing such a problem, though.

Ulf Dittmer wrote:Is the server responding in time? Meaning, can you see in the server logs that it returns something to the applet?

The logs show timely (immediate) access and response in the servlet calls prior to visiting page X, but after returning to the applet page, the server is NOT being hit - I have this set up in my IDE and I will see breakpoints in the servlet code being hit in the initial visits to the applet page, but not after visiting page X.

I have an applet which has clickable areas that redirect to jsps, and the user can then click back to the applet page. The code is done in the applet using the getAppletContext().showDocument(URL) method.
However, I have noticed after a recent build, that when I click on the link to visit page X, upon returning to the applet page, it is 9 times out of 10 FREEZING up and not responding.
I have set timeouts on the connect and read, to no avail. I see from the logging output that the applet stops responding at this line:
con = (HttpURLConnection)url.openConnection(); con.setUseCaches(false); con.setConnectTimeout(10000); con.setReadTimeout(10000); logger.debug("Timeout:" + con.getReadTimeout()); con.connect(); in = con.getInputStream(); //<---*** This line

The url it is contacting is a servlet, from which it should've been receiving a Vector object.
The Servlet has the proper code in place for closing outputstreams, but for some reason the applet cannot connect to it after that call to showDocument().
Is there something I am missing here?

thomas josephm wrote:
java.lang.Exception: ValidateAndReturnStatusToJSWithParams{0} :no such method exists
at sun.plugin.com.JavaClass.getMethod1(Unknown Source)
at sun.plugin.com.JavaClass.getDispatcher(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)

I had this problem running under JRE 1.6_06
I upgraded to JRE 1.6_13 and the problem went away (after I also cleared out all my signed applet certificates from the Java Control Panel)

Jordi Monn� wrote:More info here: http://www.salixalba.uklinux.net/willow/computing/spring.html

Even though this is a really old post, it came up for me when I was googling for the right way to output errors in a jsp.
There is a "Correction" at the bottom of that post, which clarifies that you can do this the easy way, like so:
<spring:bind path="user"> <font color="red"><c:out value="${status.errorMessage}"/></font> </spring:bind>

Try making _target1 a separate form field, instead of part of the submit button:

<input type="submit" value="Next" /> <input type="hidden" name="_target1" />

This has been working for me.

Murali Pen wrote:I couldn't get this to work after following every instruction in the spring modules online documentation. When I click the next button on my registration page (with some required fields left empty), I simply see the next page in the order. No validation is happening. Can someone help?

Thought I'd answer this really old question, since I have the answer:

From the JavaDocs of the AbstractWizardFormController:

The Validator's default validate method
will not be called by a wizard form controller

Instead, you override WizardController's method validatePage(Object, org.springframework.validation.Errors , int).

I then call a specific validation method based on the current page number. Like so:
protected void validatePage(Object command, Errors errors, int page, boolean finish) { KioskValidator val = (KioskValidator) this.getValidator(); switch(page) { //todo: can we deduce the page validator method from the request somehow? case 0: val.validateLoginPage(command, errors); default: super.validatePage(command, errors, page, finish); } }

I was having the same trouble - it seems like the key is that your welcome page needs to be able to reference the prelude file from the same relative path as all other JSP files.

I have an index.jsp which redirects to file /WEB-INF/jsp/welcome.jsp

All other jsps are in the same folder (/WEB-INF/jsp/) including the prelude and coda files.

Here's my web.xml:
<?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_4.xsd" version="2.4"> <context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/webservice.xml, /WEB-INF/dispatch-services.xml, /WEB-INF/dispatch-mvc.xml, /WEB-INF/dispatch-servlet.xml </param-value> </context-param> <!--do automatic includes --> <jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <include-prelude>prelude.jsp</include-prelude> <include-coda>coda.jsp</include-coda> </jsp-property-group> </jsp-config> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>dispatch</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatch</servlet-name> <url-pattern>*.spring</url-pattern> </servlet-mapping> </web-app>

Any JSP needs to be able to see prelude.jsp in precisely that manner.

I just came across this article, figured I would share:
http://springtips.blogspot.com/2007/07/changing-log4j-logging-levels.html

I've used it for when something unexpected happens with a custom tag and it's better than a broken jsp.

<c:forEach items="${warehouses}" var="whse"> <c:catch var="er2"> <%--TODO: <c:if test="${fn:length(warehouses) > 1}"> Not sure why this is causing problems...--%> <option value="<c:out value="${whse.identity.ID}" />" <c:if test="${status.value==whse.identity.ID}" >selected=true </c:if>> <c:out value="${whse.name}" /></option> </c:catch> <c:if test="${er2 != null}"> <option>Error: <c:out value="${er2}" /></option> </c:if> </c:forEach> </select>

It's kind of a last resort, and should be temporary until you figure out how to better handle the exception (server-side).

I would try using eq instead of ==
Not sure, but this is always one thing that trips me up when dealing in JSTL.

Might want to try Spring's own LDAP solution:
http://www.springframework.org/ldap

It seems that this error has to do with the missing CRConfig.xml. Can anyone guide me towards a resource as to how to configure this file?