The company’s use of irport configuration xml to generate .jasper suffix file and then organize the data for pdf generation. The project window environment does not report an error in the execution, placed on the liunx server sometimes encounter code stuck in the JasperFillManager.fillReport in this sentence does not move the case, and does not report an error throws an error nor backward execution. I have no idea how to troubleshoot the problem.
Today, I encountered this problem again, and solved the problem after the following troubleshooting process
1, the project itself is 5.6.0 jasperreports maven package configuration, suspected that the version is too low to store this problem, in order to verify I set up a new project, found a text on the Internet for the initial integration of code configuration is as follows
maven configuration to increase the configuration
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itextpdf</artifactId>
<version>5.5.0</version>
</dependency>
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itext-pdfa</artifactId>
<version>5.5.0</version>
</dependency>
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itext-asian</artifactId>
<version>5.2.0</version>
</dependency>
<dependency>
<groupId>cn.lesper</groupId>
<artifactId>iTextAsian</artifactId>
<version>3.0</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.11</version>
</dependency>
<!-- jasperreports end-->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
</dependency>
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>6.11.0</version>
</dependency>
Test sample code
public static void main(String[] args) throws Exception {
test();
}
public static String test() throws JRException {
Map map = (Map<String, Object>)new HashMap();
List<Object> list = new ArrayList<>();
String T1 = "1";
String T2 = "2";
String T3 = "3";
String T4 = "4";
BigDecimal T5 = new BigDecimal("0");
log.error("Fetch public data");
for (int i = 0; i < 10; i++) {
Irportbean detail=new Irportbean();
detail.setL1("1");//thisCopyDate
detail.setL2("2");//writeOffDate
detail.setL3("3");/preto
detail.setL4("4");//thisto
detail.setL5("5");//practicalWater
detail.setL6("6");//netReceiptsWater
detail.setL7("7");//basicsFeeUnitPrice
detail.setL8("8");//basicsFeeMoney
detail.setL9("9");//lateFee
detail.setL10("cancelled");//cancellation flag isWriteOff
list.add(detail);
}
JRDataSource data = new JRBeanCollectionDataSource(list);
map.put("beans", data);
map.put("T1", "test");
map.put("T2", T2);
map.put("T3", T3);
map.put("T4", T4);
map.put("T5", T5);
log.error("---------------------------map :" + list.toString());
// 3. print PDF
String imageName = UUID.randomUUID() + ".pdf";
log.error("==========");
log.error(PATH + "gr_water_list.jasper");
log.error(IAMGE_PATH + imageName);
JasperPrint print = JasperFillManager.fillReport(PATH + "gr_water_list.jasper", map, new JREmptyDataSource());
JasperExportManager.exportReportToPdfFile(print,IAMGE_PATH+imageName);
log.error("---------------------------getName :" + print.getName());
String url = YUMIN + "JxReport/temp_image/" + imageName;
log.error("---------------------------url :" + url);
return url;
}
The code local window execution OK, and then packaged to the problem server through the interface test found that the normal generation of pdf, the initial confirmation of the text and the server is not related to confirm the version of the problem.
After confirming that the version of the project is integrated in accordance with the above configuration integrated into the existing project packaging test. The process also encountered two small problems
1, integration test local test no problem, put to the server found or not, found that eclipse using maven packaging if not prior to update maven and clean up the existing war, it will be the new version of the jar and the old version of the jar packaged together to war, you need to clean up the project maven. then repackaged, the phenomenon: war start after decompression lib directory See if the new package and the old jar exist at the same time, the existence of the old jar to remove, restart the project found that the problem is solved.
