twoods

Never got a resolution. We swiched back to using the multi-threaded runner. My take on this is that Jasper got "excited" about the continuation solution for awhile (per the Ultimate Guide) but abandoned seeking a solid resolution for this problem when it appeared to be out of the scope of Jasper's code. See: http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=92700#92700

Should we be using JRThreadSubreportRunner and only use JRContinuationSubreportRunner if we experience problems with the former? Or the other way around? Since philosophies can change as operating systems and hardware improve, what is the currently recommended option here? BACKGROUND: The Ultimate Guide 3 (page 168) seems to argue in favor of JRContinuationSubreportRunner over JRThreadSubreportRunner, so we have been using the JRContinuationSubreportRunner in production for about a year. However recently on servers running newer versions of the Sun 1.6 JVM with Tomcat we are consistently experiencing the StackOverflowError with complex sub-reports as described in detail these posts: http://jasperforge.org/projects/jasperreports/tracker/view.php?id=5015 http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=79134&topid=91425 We have applied the recommended solution of disabling the logging with no success. -Tad

The problem seems to be that Date values (i.e. produced when IS_DETECT_CELL_TYPE is True) will display in Excel as they were "formatted" on the server that produced the Worksheet regardless of the TimeZone of the client that views the Worksheet. Excel doesn't display any TimeZone indicator (e.g. EST or PST). In other words, the TimeZone that gets applied when Dates are formatted as Strings by Jasper is apparently not used by JExcelApi or Excel (furthermore excel doesn't appear to support any time zone formatting characters), so a raw Date VALUE given to JExcelApiExporter needs to be parsed to a Date value that will display for the desired time zone but when formatted in the TimeZone of the server. For example, assume your Jasper server is running in EST. A 10am EST / 7am PST Date that you want to report as "7am" PST will show "10am" in Excel because JExcelApi ignores Jasper's formatting TimeZone information when it creates the Excel worksheet. So Jasper needs to create a date that will display as "7am" in the server's TimeZone. To fix the problem, I overrode the JExcelApiExporter's getTextTimeZone method (which appears to only be called when IS_DETECT_CELL_TYPE is True). private class FixDateTimeZoneExcelApiExporter extends JExcelApiExporter { @Override protected TimeZone getTextTimeZone(JRPrintText text) { return TimeZone.getDefault(); } } My reports now show correct Date-Times in HTML, PDF, and Excel (when IS_DETECT_CELL_TYPE is True or False). I tested this with JExcelApiExporter but NOT JRXlsExporter. Any comments? Post Edited by twoods at 09/10/2011 21:47

When exporting a report, the parameter REPORT_TIME_ZONE works great to format dates in a desired time zone. However when exporting to Excel (JExcelApi in Jasper version 4.0.1) and IS_DETECT_CELL_TYPE is True, the Time Zone reverts to the time zone of the server. Is there a parameter or some way to make the parser used when IS_DETECT_CELL_TYPE is True do its parsing for the desired time zone, which would not necessarily be the server's (or the JVMs) default time zone? -Tad Post Edited by twoods at 09/10/2011 15:13

Can someone who has permanently solved this problem please provide some detail on how they sovled it? We have one Linux server running Tomcat 6.0.32 and JVM 1.6.0_26 that we cannot solve this on; the server does not have any debug logging enabled, and we have tried to explicitly "disabled" such logging as suggested in this discussion. The offending report (which includes an overflowing subreport) works fine on similar servers (although with slightly older versions of the 1.6 JVM). We have not been able to identify anything else different about the particular server that experiences the StackOverflowError. Alternatively or additionally, if someone could tell me how to find a copy of the javaflow source code aligned with the distribution of Jasper Reports I would be glad to do some further research within the code. The javaflow source at http://svn.apache.org/repos/asf is newer. -Tad

Running Jasper Reports 4.0.1 using javaflow we are experiencing the exact same StackOverflowError and stack trace under the same condition of multi-page reports where sub-reports roll-over to another page, as posted by ceday on 1/7/2011 in issue tracker: http://jasperforge.org/projects/jasperreports/tracker/view.php?id=5015 A few posted topics on this issue point back to this discussion as the solution by using a log4j.properties file containing this: log4j.logger.org.apache.commons.javaflow=info I have been experimenting with the placement of this log4j.properties file without success. The StackOverflow error happens in some environments and not others, and when it does happen it is consistent. I am not sold on the conclusion that the problem is a javaflow and logging problem, and am inclined to believe that the problem is something else that happens to be "covered up" by turning logging off. But I could be wrong and if there is more evidence to show that it is a logging problem and some more specific steps on exactly what to disable where then I am willing to try anything. ... I have some environments where I cannot make the problem occur including by trying to enable logging, so the problem is most elusive. We have tried various memory configuration parameters with no change. ... I have downloaded the javaflow source code (which is newer and out of sync with what is being distributed with even Jasper 4.1.1), to see if I can figure out what is really going on, but haven't made much progress yet. In any case, this issue bothers us significantly. The Ultimate Guide 3 seems to argue the case for javaflow, but in reality how concerned should we be able running the threaded solution instead? Our offending report is a complex with potentially dozens of pages and 3 or 4 nested subreports, but 2 pages of it are enough to cause the StackOverflow. Post Edited by twoods at 08/30/2011 02:42

When isPrintRepeatedValues=false and the value's case changes in the value gets repeated. Is there a flag or preference at any level (e.g. report, field) that will cause this comparison to be case insensitive? -Tad

I prefer the way that the Arial font renders to the DejaVu Sans font. Where can I find an Arial or Helvetica font that can be legally bundled in a font extension jar for use with JasperReports? I tried to use iReport to bundle the Arial font in Windows 7, but that fails with what looks like a security/access error. I'm not sure which TrueType format to buy from somewhere like fonts.com and I don't want to find out after buying it that it doesn't work or isn't legal to embed into a PDF. Suggestions? -Tad Post Edited by twoods at 06/03/2011 04:21

Looks like "net.sf.jasperreports.print.keep.full.text" was the property that I was looking for.

I have master report A, that includes sub-report B. Sub-report B has multiple columns and includes sub-report C in B's detail band. There are a variable number of records in all 3 reports. I want to fill sub-report B's columns horizontally, but when I do that it often produces the error "subreport overflowed on a band that does not support overflow." If I set sub-report B's height to a fixed size large enough to hold the maximum height of any potential record produced by sub-report C, then it works horizontally but wastes a lot of space for any records that don't produce tall sub-report Cs. Interestingly in the cases where horizontal fill works, it will stretch sub-report B's detail band so long as it fits at least one row of sub-report C; this doesn't make sense to me that it will do this but otherwise seems to require a minimum height as I described. Alternatively if I set sub-report B to fill vertically it works, but that ends up wasting a lot of space in the right margin. I would much prefer to fill horizontally in this case. Is there any way to fill horizontally with a component that has dynamic height and stretch the enclosing band accordingly? I have tried with Lists as well and experience similar problems. The only solution I see right now is to programatically estimate the page height for sub-report B by pre-analyzing my data (yuk).

I am achieving dymanic headers by setting headers' text expressions to a value that I pass in through a parameter or field (e.g. $P{MyHeaderLabel}). In group headers where I want to change some headers dymanically throughout the report, I have one of the fields reference a Map of header labels (e.g. $F{MyMapOfHeaders}.get("MyHeaderLabel")). To achieve a dynamic number of column headers I use a List component (ordered horizontally) and set its data source to the Map of headers. Maybe there is an easier way but this is working for me. -Tad

I have never been able to get this property to work. Am I I misunderstanding how it is supposed to work? <property name="net.sf.jasperreports.text.truncate.at.full" value="true"/> I would exepct that when a text field is set to a fixed width and StretchWithOverflow is set false, but net.sf.jasperreports.text.truncate.at.full is set true, then the field, when exported to Excel, would retain the fixed width but receive all of the original String content. However my experience so far (with version 4.0.1) is that the String still gets truncated to the width of the field as it would if exported to HTML or a PDF. Are there any other parameters that I must configure to get this to work? I do NOT want the cell to stretch, I just want it to receive all of the original content. I have tried setting IS_DETECT_CELL_TYPE to true but that doesn't make any difference. I have tried placing this property under the <jasperReport> element as well as the <reportElement>. -Tad

This is something else that also started happening to me with version 4.0.2. Was not a problem with 4.0.1. In my case, what was rendered as: "Page X of Y" where "Page X of" was a right justified field and "Y" was an adjacent left justified field, is now rendered as follows no matter how wide or separated I made these two fields: "Page X of Y"

I experienced the same thing moving from 4.0.1 to 4.0.2.

I would like to add that I had several reports originally created in iReport 4.0.1, run in JasperReports 4.0.1, that had labels/fields back-to-back that worked fine in those versions. Now that I have upgraded to 4.0.2 every other field disappears in HTML and Excel output but still displays properly in PDF. If I fix the fields to not end/start directly on top of each other it seems to fix the issue. I also have some fields that in 4.0.2 are set to bottom alignment but now display 10 or so pixels farther below the bottom.