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