andrewsc

Hi, we have a report which can be exported just fine to HTML, but fails when exporting to PDF. The problem is that the image is being loaded from a URL, but we designed the report to load images from the file system. The flow is something like this: - fillReportToFile - reload the file into a JasperPrint object - JRHtmlExporter..exportReport(); // this works fine - reload the same file again into a JasperPrint object - JRPdfExporter.exportReport(); // this fails The stacktrace is: net.sf.jasperreports.engine.JRException: Error loading byte data : https://my.host.com:9090/MyAppName/images_directory/my_image.jsp at net.sf.jasperreports.engine.util.JRLoader.loadBytes(JRLoader.java:350) at net.sf.jasperreports.engine.util.JRLoader.loadBytesFromLocation(JRLoader.java:467) at net.sf.jasperreports.engine.util.JRLoader.loadBytesFromLocation(JRLoader.java:428) at net.sf.jasperreports.engine.JRImageRenderer.getImageData(JRImageRenderer.java:402) at net.sf.jasperreports.engine.JRImageRenderer.getOnErrorRendererForImageData(JRImageRenderer.java:290) at net.sf.jasperreports.engine.export.JRPdfExporter.exportImage(JRPdfExporter.java:1058) at net.sf.jasperreports.engine.export.JRPdfExporter.exportElements(JRPdfExporter.java:675) at net.sf.jasperreports.engine.export.JRPdfExporter.exportPage(JRPdfExporter.java:641) at net.sf.jasperreports.engine.export.JRPdfExporter.exportReportToStream(JRPdfExporter.java:536) at net.sf.jasperreports.engine.export.JRPdfExporter.exportReport(JRPdfExporter.java:323) I could reproduce this with Eclipse debugger. In the JRPdfExporter.exportImage method, I could see the "renderer" attached to the JRPrintImage argument already had an imageLocation formatted as a URL. I wonder how could we avoid this. We would like the "imageLocation" to resolve to the file system. This application runs under WebSphere, and the file system will resolve relative to the application root. This seems to be happening elsewhere in the application. Is there any parameter in the PDF exporter, to force images to resolve from file system ? I cannot find it in the book. The report design already uses an IMAGES_DIR parameter as string, but that is not an exportter parameter. Regards, Andrew P.S. in this case, the failure is caled by an invalid httpS ceritficate, but this is not the point. The stacktrace continues: Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: No trusted certificate found at com.ibm.jsse2.n.a(n.java:37) at com.ibm.jsse2.jc.a(jc.java:388) at com.ibm.jsse2.db.a(db.java:390) at com.ibm.jsse2.db.a(db.java:161) at com.ibm.jsse2.eb.a(eb.java:20) at com.ibm.jsse2.eb.a(eb.java:152) at com.ibm.jsse2.db.m(db.java:303) at com.ibm.jsse2.db.a(db.java:230) at com.ibm.jsse2.jc.a(jc.java:446) at com.ibm.jsse2.jc.g(jc.java:433) at com.ibm.jsse2.jc.a(jc.java:335) at com.ibm.jsse2.jc.startHandshake(jc.java:523) at com.ibm.net.ssl.www2.protocol.https.b.afterConnect(b.java:122) at com.ibm.net.ssl.www2.protocol.https.c.connect(c.java:43) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:943) at com.ibm.net.ssl.www2.protocol.https.a.getInputStream(a.java:66) at java.net.URL.openStream(URL.java:1042) at net.sf.jasperreports.engine.util.JRLoader.loadBytes(JRLoader.java:336)

lucianc Wrote: Try log4j.logger.net.sf.jasperreports=debug. Do these issues occur determinisically? Regards, Lucian Thanks for your help, I will try the log settings. Meanwhile I added more logging to our application and identified the issue. Apparently, the developers have not used the Token interceptor in Struts2, so a double-click on the front-end triggered parallel threads in the Web container. Two threads were calling fillReportToFile at the same time with the same file name. No wonder the file was corrupted. So, there is no suggestion of Jasper Reports doing anything wrong here. On contrary, it is a great tool. On a personal note, I studied engineering, but being older now, I live mostly by my business knowledge. Occasionally, I still enjoy a technical challenge, like this bug which was with us for three months, until I finally caught it today. Regards, Andrei Schonberger Institutul Politechnic Bucuresti Facultatea de Automatica si Calculatoare, 1975

Hi, I'm chasing a serialization bug, and I'd like to turn on the internal logging of JasperReports. Our J2EE application uses log4j so I added the following to the config file, next to other application-level loggers: log4j.category.net.sf.jasperreports=DEBUG,jasperlog log4j.appender.jasperlog.layout=org.apache.log4j.PatternLayout log4j.appender.jasperlog.layout.ConversionPattern=[%d{dd MMM yyyy HH:mm:ss,SSS}] - %t - [%c] %-5p: %m%n log4j.appender.jasperlog=org.apache.log4j.FileAppender log4j.appender.jasperlog.File=/my/full/path/Jasper.log The above has created an empty file, but no log messages. What am I missing ? Should I also turn on the "warning" and "error" level ? I'm not specialist in log4j but people in this forum have faced this problem before. A bit of background. We are converting a client-server application to Web. The issues we are facing a similar to the ones brought up by other forum members ( Tracker: 1262 , 2621 , 3651, also Forum topics: 52654, 44620 ). The client-server application was sending large results to the desktop. On the fat client, users were manipulating the data in ways we could not fully predict (filter, sort, scroll up-down, save to Excel, etc). Such behaviour is difficult to implement with a Web container and JasperReports. Those large result sets were a manifestation of incomplete analysis and insufficiently defined business processes. Many years ago, we did not know how exactly users were going to manipulate the read-only data. The users themselves did not want any limitations imposed upon them, and were happy to navigate the data like in a spreadsheet. With a browser-based interface, this will need to change over time, by introducing more structured navigation which will avoid large result sets. For the moment, the expectations have been set to a low level, and users understand the system will be slow with the large reports. After three months fighting the de-serialization issue, we would be happy if the application was just as slow as the 15-year old Powerbuilder system, despite JasperReports running on hardware which is 8 times faster. We just need an immediate solution which does not crash the Http session and does not cause WebSphere to run out of memory. The good thing is that we are only in a testing stage. When we load a serialised JasperPrint object, we get various errors, all indicating the serialized stream was corrupted. The errors come from JRVirtualPrintPage.readObject method, most often from line number 401: virtualizationContext = (JRVirtualizationContext) in.readObject(); Sometimes, the error is from a few lines down in the same method, in one of the other calls which read from the stream. Our code follows a pattern like this: jrSwapFile = new JRSwapFile (...) ; virtualizer = new JRSwapFileVirtualizer( .., .., jrSwapFile ); parameters.put(JRParameter.REPORT_VIRTUALIZER, virtualizer); parameters.put(JRParameter.IS_IGNORE_PAGINATION, Boolean.FALSE); JasperFillManager.fillReportToFile( ...,file_name,.. ) ; // file_name is unique virtualizer.cleanup(); // now reload the file we have just saved // Use a separate swap file and a new virtualizer // as per issue 4001 jrSwapFile = new JRSwapFile(...) ; virtualizer = new JRSwapFileVirtualizer( .., .., jrSwapFile ); JRVirtualizationHelper.setThreadVirtualizer(virtualizer); JRLoader.loadObject( filename ); // same file as we just saved We get various errors, all indicating the serialized stream was corrupted. The errors come from JRVirtualPrintPage.readObject method, most often from line number 401: virtualizationContext = (JRVirtualizationContext) in.readObject(); The error shows up when there is a bit of system load and multiple heavy reports running in the web container. We went from FileVirtualizer to SwapVirtualizer but it did not help. Luckly, we are not in production yet, and the errors comes up regularly during testing. So, our best chance for catching it is to turn on logging. I'm glad Issue 3651 is elevating to "critical" the need for virtualizing non-paginated reports. Also, Issue 4001 was solved, but I don't know whether it is part of 3.5.2. Anyway, logging will tell us what is happening. Regards, Andrew Post Edited by andrewsc at 28/06/2009 13:49

Hi Diwakar, I'm scrutinizing the way in which the JRSwapFile constructor creates a unique file name. It contains the identityHashCode and the current time. Strictly speaking, the VM specification does not guarantee this to be unique. The granularity of the time is not always as fine as a millisecond. In theory, different objects may hash to the same integer. In practice, I don't know how much this should be a concern, but if it happens once a year, then it is a bad year -:) I'm tempted to subclass JRSwapFile, and use a unique number allocator from a static Integer. If there is a power failure, files may be left behind. In order to avoid inadvertently reusing a file, we could keep the existing truncate logic. Or, the unique number allocator, at its first invocation, could delete all files in the directory. Something like: private static long unique_id = 0; private static synchronized long allocate_unique( String directory ) { if ( 0 == unique_id ) { // This is the first invocation, after startup. // Delete all files in "directory", in case they were left behind. } unique_id ++; return unique_id ; } Or, we could leave the task of allocating a unique ID to the application. Most applications already have some kind of unique identifier for each JasperPrint instance, and we could bring a unique ID from the database. Regards, Andrew Post Edited by andrewsc at 08/06/2009 20:57

We are getting similar errors during deserialization, with JRVirtualPrintPage.readObject in the stacktrace. First, we create a new instance of JRFileVirtualizer for each report being filled with JasperFillManager.fillReportToFile But all of these File Virtualizer objects use the same directory (and the maxSize is set to 1 which is probably too small). Later, when the JasperPrint is de-serialized from the file, our development team has passed no virtualizer to the ThreadLocal context. So, reports which have been saved without error, run out of memory when the system reads them again from disk. This makse sense. If there is sufficient memory, we still get errors like "stream corrupted" during deserialization. I understand the best solution for de-serialization would be to create a separate directory, and install a virtualizer on the thread before we call loadObject(). From what you told us about the bug, it could not run the virtualizer in the same common directory, because the IDs of objects may clash with their previous values used at serialization. However, it would be more elegant if we could always use the same virtualization directory. Which version is going to include the fix made to JRVirtualPrintPage ? regards, Andrew Post Edited by andrewsc at 06/06/2009 17:51 Post Edited by andrewsc at 06/06/2009 17:59

this forum is great - I just found the answer to my current problem. Thanks Andrew Post Edited by andrewsc at 06/06/2009 18:01

Hi, I'm maintaining a system which uses subreports based on Oracle reference cursors. The subreports have their own custom data sources. So far, the subreports have never been invoked in a loop. In other words, the master report had only one Detail row filled with data. Therefore, the subreports could simply use their respective custom datasources. Now, we are planning a new report, which will have multiple detail rows in the master (e.g. multiple customer accounts). For each detail of the master, we need to print a subreport (e.g. the transactions of the customer). We can pass the parameter "account_number" from master to subreport. But I just don't know how to tell the custom data source, to use the parameter. To make it more clear: - at first invocation of the subreport, the parameter value "46823" should be passed to the datasource, which calls the Oracle procedure - at second invocation of the same subreport, the parameter value "17253" should be passed to the same datasource. Is this possible ? If the datasource was an Sql Query, it would work. But my datasource is a custom Java object. I looked at the JRDataSourceProvider interface, but it does not seem to apply at runtime. Regards, Andrew