Recompiling reports when new version of Jasper Server is installed

[bdmayes]

I am working on Jasper reports for my company's application and am in the process of upgrading the engine from 3.7.2 to 4.0.0.  I swapped out the jar files and re-built everything and several reports worked fine.  Others threw NullPointerExceptions and some of them even gave me errors such as "Font '' is not available to the JVM. See the Javadoc for more details."

The NullPointerExceptions seem to be resolved by downloading the .jrxml file, compiling it the newer version of iReport, and then uploading the .jrxml file again (I can only assume that this process somehow modifies the .jrxml file to conform to the specs for the latest version of Jasper).  The second issue was more complex and involved some malformed XML inside of the .jrxml files themselves, even after recompiling the reports.  Specifically, the lines would specify a font with the empty string like this:

<font fontName="" pdfFontName="Arial" size="10" isBold="true"/>

I had to manually edit all the problematic files and change them such that some font was specified.  For example:

<font fontName="Arial" pdfFontName="Arial" size="10" isBold="true"/>

 

Problems with malformed XML aside, it seems that reports compiled in an older version of iReport do not always play nicely when using the latest Jasper engine (I found numerous forum posts where people were instructed to recompile the .jrxml file in the latest version of iReport).  Apparently recompiling is a fairly common task, and my understanding is that when this process is done, the XML file is updated to the format that this new version of iReport uses (and ultimately what the new version of the engine requires).  This process is fine if you only have a few reports, but we have hundreds of reports, and most of them have several subreports.  It's a pain to recompile all of these manually.

As I mentioned before, the fix when we upgrade the Jasper engine is generally to download the .jrxml file from our server, recompile it in the new iReport (in this case I'm using 4.0.1 and the jasperreports-4.0.0.jar file), and then overwrite the existing file on the server with the new .jrxml.  Oddly enough the bytecode (.jasper file) can be ignored -- uploading the .jrxml file is sufficient.

After doing some research it turns out that the reason that uploading the .jrxml file alone is sufficient is because we actually store the uploaded XML in our database as well as call the JasperCompileManager.compileReportToStream() method inside of the Jasper engine.  The resulting bytecode is then stored in a BLOB column in our database.  My questions are therefore:

 

1. When are the .jrxml files updated?  Clearly something in them changes just by opening them in iReport and recompiling and I don't even have to click save.  So is it the compilation process that updates the .jrxml files or does it happen when the report is first opened by iReport?

2. If changes to the .jrxml file do NOT occur during compilation then is there some way to pass XML into a method and receive the newly updated version of it?

 

 

Ultimately I would like to create a job that will automatically loop through all .jrxml files, update them, and then recompile them with the latest version.  I can then write the updated XML and updated bytecode back to the table in our DB.  I know that they can be recompiled by calling JasperCompileManager.compileReportToStream() but I don't know if that process also updates the .jrxml file or if there is some other method that can be called to perform that process.  If anybody knows I would greatly appreciate the answer!  :)

Post Edited by bdmayes at 03/22/2011 21:08

[mdahlman]

The subject to your post mentions "Jasper Server", but the body doesn't mention this at all. If you are using JasperServer, then your simplest solution is probably to delete the contents of jirepositorycache in the repository. Once the compiled files are gone, then the next call to any report will necessarily recompile it.

The .jasper files are normally compatible with later releases of JasperReports... but not always. The .jrxml files, on the other hand, have fantastic compatibility with later releases of JasperReports. So all reports ought to work.

Regards,
Matt

[bdmayes]

 Ok so I guess the problem isn't necessarily when JasperServer is upgraded, but the actual Jasper engine itself (which I assume is included in JasperServer).  Specifically, we are upgrading the jasperreports-3.7.2.jar to jasperreports-4.0.0.jar.  We recently purchased a professional license but at the moment have not integrated JasperServer...

I'm not sure that my question was really answered, though I think it was.  You said that the .jrxml files have "fantastic compatibility with later releases of JasperReports" but that doesn't seem to be the case, unless it's actually our bytecode that is the problem.  So right now we do this:

 

1. upgrade the Jasper engine in our app

2. login and notice that many Jasper reports are not working

3. download the newer version of iReport (which matches the upgraded version of the engine from step 1)

4. download the .jrxml file from our server and then compile it with the latest version of iReport

5. upload the .jrxml file back to the server (throwing away the .jasper file as we compile the code anyway when the .jrxml file is uploaded)

 

If what you're saying is correct, then recompiling in iReport (step 4) is essentially pointless -- all we really need to do is to call JasperCompileManager.compileReportToStream() and save away that new bytecode (e.g. the .jrxml file isn't really changing format at any time).  If so then it seems that given the exact same input file (.jrxml) the 3.7.2 engine can/may generate different bytecode inside of compileReportToStream() than the 4.0.0 version will.  Is that correct?

If so it makes my life easy since the only thing we would have to do is loop through each row in the table, pull out the XML code, compile it with the JasperCompileManager class, and then save it back into the BLOB in the same row.  Any additional thoughts?

[bdmayes]

 Ok I have made some progress.  I wrote a simple test class and finally sorted through all of the jar files that needed to be in CLASSPATH to execute...after calling compileReportToStream() I found that the 3.7.2 version of the jar and 4.0.0 version of the jar did indeed generate different bytecode.  So that answers that question.

I am 99% certain that the jrxml files do not change format via the compilation button in iReport.  In fact, that makes sense -- the xml *shouldn't* change unless the user explicitly add a new variable/parameter/field, changes the properties of something, adds a band, etc.

 

So I think I'm good to go here unless anyone has anything further to add.  I still have problems with the font stuff not working correctly but the JasperReports forum seems like a better place for that.

[marall80]

i had ireport 3.6.0 and upgraded to 4.0.2 and i just recompiled my  reports.

and also we updated old files to  jasperreports-4.0.2.jar  ,applet,font and javaflow.are they enough?

but my report don't work properly.

what shoud i do now?

please help me