Servlet build error using Aspose.Words for JasperReports

Hi everybody.


I’ve just downloaded the evaluation version of Aspose.Words for JasperReports, 'cause my company needs a way to generate decent .doc reports out of the application it sells, and not just those ugly .rtf reports JasperReports create.

After downloading the .zip file containing all the material, I moved the .jar with the library to the lib/ folder of the servlet installation, then I modified the servlet which creates the report to give it the ability to export .doc reports, but when I try to compile it I get this error:

SingleReport.java [33:1] cannot access com.aspose.words.jasperreports.AWDocExporter
bad class file: C:\AGEws\tomcat\webapps\626express\WEB-INF\lib\aspose.words.jasperreports.jar(com/aspose/words/jasperreports/AWDocExporter.class)
class file has wrong version 49.0, should be 48.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
import com.aspose.words.jasperreports.AWDocExporter;

I cannot really understand what it means. Can you help me? I’m using JasperReports 3.0.0 and Sun ONE Studio 5 as my Java IDE.

If I try to remove the explicit import statement which causes the error and leave only the “*” import statement, I get the same error.

EDIT:

I was able to correct this issue, it was just due to using the wrong version of Java JDK. Now the servlet compiles correctly but when trying it, we get an error page:

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException
SingleReport.CompileReport(SingleReport.java:876)
SingleReport.processRequest(SingleReport.java:127)
SingleReport.doPost(SingleReport.java:213)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause

net.sf.jasperreports.engine.JRException
com.aspose.words.jasperreports.AWAbstractExporter.exportReport(Unknown Source)
SingleReport.CompileReport(SingleReport.java:873)
SingleReport.processRequest(SingleReport.java:127)
SingleReport.doPost(SingleReport.java:213)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

I’m including the servlet source code hoping it might help. It was not written by me, I just tried to modify it in order to make it work using Aspose.Words, so it is difficult for me to say where the error lies.
EDIT 2: attachment removed, it was the wrong file. I’ve attached it on a later post.

Hi,

Thank you for your request. Could you please attach a .jrprint of the report that fails?

I would gladly do it, but I’m quite new to this technology and do not know how to use it well, I’m sorry. What is a .jrprint, how can I extract it?


EDIT: ok, I checked what you mean. I could just attach the .jrprint of ANY report, 'cause they all fail to print. I’ll do it ASAP, just the time to make some more test to verify it is not my fault caused when I modified the print servlet.

Ok, now, I made some more test, and I still don’t get even close to the print itself. The problem seems to be within the servlet: whenever I try to print I still get an exception


net.sf.jasperreports.engine.JRException
com.aspose.words.jasperreports.AWAbstractExporter.exportReport(Unknown Source)
SingleReport.CompileReport(SingleReport.java:875)
SingleReport.processRequest(SingleReport.java:127)
SingleReport.doPost(SingleReport.java:213)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

but I do not know how to solve it. I mean, the servlet is compiled correctly, so I’d say that the Aspose.Words library is correctly “seen” at building time, but I still get this error.

I have attached the full servlet code, so that perhaps someone with a better understanding than me of how JasperReports works could give me some help. The one I attached in the first post is actually the wrong servlet, sorry, I’ll remove it now if it is possible.

EDIT: supposing it is NOT the servlet itself causing all this trouble, how do I create a .jrprint to attach it for you to analyze?

EDIT 2: I’ve give it a look, and we do not use .jrprint to print reports. I mean that we have our .xml report templates which are compiled directly in the servlet. I’ll see if there is a way to obtain the .jrprint from there.

I’ve been able to create a test .jrprint file by inserting a call to JasperFillManager.fillReportToFile just after the creation of the JasperPrint object. I’m attaching it to this post as requested before, I hope that helps together with the servlet code I’ve already posted.


EDIT: I know that making pressure usually does not work, but we REALLY need to be able to at least try out this product, and the installation guide is far from sufficient in helping me know what mistake I’ve made in “installing” the library…

Sorry for leaving you alone with your problems, now that you have obtained a .jrprint eventually will allow me easily understand what the problem is. And this is not pressure at all, bugs should be fixed :) I will let you know immediately once I have got some result.

Thanks.

I have fixed the issue. It had to do with the fact your report contained an empty image (with no data at all).

I'm attaching a fixed build. Please try it out and let me know how it goes.

Thanks.

I will try it right away!


The empty image represents a company logo, but since not all our customers have a personal logo (like the one of the example .jrprint I’ve sent you) sometimes that image is “empty”

Ok, we have done quite several tests, and found out some minor and major problems that we’d like to ask you if it is possible to fix in some way. I’m also attaching an archive containing the following:

- 3 .doc report print, which show how your library creates them
- 3 .docx report print, which show how your library creates them
- 3 .rtf report print, which show how the standard JasperReports RTF library creates them
- 3 .jrprint file (one for each report, just in case they might be useful to you)
- the .xml files defining the layout of those reports (not sure if you’d need them, but just in case)

[BTW, all this problems do not relate with the original topic title, but I wasn’t sure if I really should open a new one. Also, in the archive, I’ve stripped out the watermark so that it is easier to see the document content.]

So, starting with the minor problems (which I think could possibly be fixed by re-designing the report template, but I’m not sure if this can fix them ALL) referring to reports 0_1 and 1_2_1
- as you can see, the page header is different, it has lost those nice round borders (actually, in the .doc/.docx version, it has no border at all)
- the page footer is different, it misses a line on the left of the image (this is REALLY a minor problem, we can just take the footer as it is, but I preferred to report it anyway)
- sometimes there are unwanted blank pages, seems due to page break problem: the page breaks sometimes are put too “late”
- in the .docx reports, the page footer is quite too big, and it looks different if I open it under Word 2003 or Word 2007
- allignment is different between .doc and .docx report format, even though they are the same report with the same content (as for the footer problem, this is REALLY a minor problem, but I preferred to report it anyway)

Anyway, as I said, the problems listed above are minor problems, which we’d surely like to be able to fix, but the major problem I see here (again, speaking of reports 0_1 and 1_2_1), and this is really a great deal for us, is that the page header and footer are in the document body and not in the right header and footer sections, so if one of our customers modifies the document by removing (or adding) text, the page header and footer will end up in the wrong position, giving us no advantage against the .rtf format, since each page has its own header and footer (I’m not sure if I really explained myself here. I it is not clear, please ask and I’ll try to clarify what I mean).

Moving to report 99_5_1, which is a very big one (it’s made of 30+ subreports), well, here we have a HUGE problem. Both the .doc and .docx reports are completely wrong, not even CLOSE to what we’d like to obtain (which is obviously a .doc easily-editable version of the .rtf). I really hope there is a way to fix this, 'cause if there is not we’ll need to look somewhere else to find our reporting solution.

Lastly, I’d like to thank you :slight_smile: we’ve NEVER received such high-quality customer support, and we hope you’ll be able to help us fixing our problems with your software. If you need more information, just let me know and I’ll do my best to provide you all you need.

EDIT: please notice that the 99_5_1 report is made using a different servlet, which is similar to the one that made the 0_1 and 1_2_1 report, but with some differences. I’m attaching it here just in case it helps.

I'll take a look at the minor issues and report 99_5_1 (which might appear way too complex for the flow layout export), but I would like to comment on the huge page header/footer problem first. This issue was also raised by another user in the forum some time ago. And this is a major problem for us, too.

The point is the JasperReports print model (used by the exporters) lacks any information about headers and footers of the page. So we simply do not know whether a particular element belongs to a header/footer or the body of the report. This is what we would really like to resolve because Word documents should have header/footer contents in the appropriate section stories, not in the body. We posted a request in the JasperReports forums recently regarding this problem but JasperReports developers seem to be ignoring it so far.

I have no idea as to what to do on this matter at the moment. There's no a decent workaround for that. What we are currently discussing is customizing JasperReports (as it is an open source project) to achieve the export which is demanded by our users that extensively.

Thanks.

Hi,

We have found a way to detect the area a report element belongs to. Please expect the header/footer feature shortly. I'm going to comment on the minor issues ASAP as well.

Thanks.

DmitryV:

I'll take a look at the minor issues and report 99_5_1 (which might appear way too complex for the flow layout export)

If I may say something about report 99_5_1 (which I gave you the template), I wouldn't define it "complex", just very long, with many subreports. I mean, its layout isn't more complex than many other reports we use which are printed correctly by Aspose.Words (except for header/footer issues), with text, tables and images and whatever. Why would the length of a report be a problem for the report generation?

I’d like to add a new question: do you think you’ll be able to fix our issue in document like 99_5_1? It is VERY important for us to know because it will greatly influence our decision wether to buy an OEM license for this product or start looking elsewhere, and we’d need to become productive as soon as possible.

I think we’ll be able to fix the issues there. Give me 1-2 days for more investigation. I’ll then get back to you and let you know the result.

Ok, thank you for all your support!


EDIT: if you need more material to work on, like more example reports, templates or .jrprint, just let me know and I’ll be happy to help you help us.

Any news about the solution to the issues we pointed out?

Sure. Sorry for delay. Let me comment on the issues step by step, starting with minor ones.

  1. Rounded corners. It is impossible to have rounded corners in flow layout documents. So this is an issue that simply cannot be resolved.
  2. Missed lines. Lines and rectangles are disabled for export by default. The reason is that lines are often used as borders in JasperReport design, i.e. placed over text elements. Flow layout does not support overlapping items. So consider the EXPORT_LINES and EXPORT_RECTANGLES parameters in the following class: http://www.aspose.com/documentation/jasperreports-exporters/aspose.words-for-jasperreports/com/aspose/words/jasperreports/awexporterparameter.html. Try setting the first one or both to true and see the result. If the export isn't missed, then it works okay for your design. BTW, these parameters seem to be missing from the server bean... we'll fix this ASAP, please expect it in the next hotfix.
  3. Headers/footers. We've almost finished working on implementing natural headers and footers in exported documents. The release was postponed to forthcoming Monday.
  4. Messed up contents/the huge report. This is a major issue indeed. Whenever you see document contents messed up, the main reason is most probably as follows: text elements in the report design overlap. This isn't an issue when you export text elements as textboxes; but if you want to build a document from "normal" paragraphs, this is a real hassle. We do use a special overlap resolution algorithm that tries to relieve the situation, but it may fail if the overlappings are numerous. This is exactly what takes place, for instance, in the header of your reports. So would it be possible to get rid of overlappings completely? We are working on improving the algorithm but can't promise it will be able to manage any complicated input.

Thanks.

Thanks for your quick answer. At this point, since we would have to at least check each of our report template, it’d be better for us to just remake them from scratch in order to user Aspose.Words for Java, which I’ve been intensively testing in these day, and it handles our report much better than Jasper Report could ever do, thanks to the mail merge feature. So I think we’ll just move to the library for Java instead the one for jasperreports.


Anyway, thanks for all the support you’ve given me!

After some tests, after your suggestion to look for overlapping fields, we have discovered that removing the background image greatly helps in obtaining a correctly formatted document, but still quite far away from what we are looking for. Anyway I think we’ll go on testing, and we’ll also request a temporary license in order to try the library with no limitations.

Yes, I forgot to say the image is one of the causes too. Also, get rid of overlappings in the header.