Jump to content
We've recently updated our Privacy Statement, available here ×

teodord

Members
  • Posts

    5,346
  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Profiles

Forum

Events

Featured Visualizations

Knowledge Base

Documentation (PDF Downloads)

Blog

Documentation (Test Area)

Documentation

Dr. Jaspersoft Webinar Series

Downloads

Everything posted by teodord

  1. Changed Resolution from Open to Fixed Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi,Starting with version 6.4.3, groups have a new boolean attribute called preventOrphan.In addition to this, groups also have a new property called minDetailsToStartFromTop, which would help make sure groups do not start too low on the page and at least a specified number of detail records fit into the remaining space.I hope this helps.Teodor
  2. Hi, Starting with version 6.4.3, groups have a new boolean attribute called preventOrphan. In addition to this, groups also have a new property called minDetailsToStartFromTop, which would help make sure groups do not start too low on the page and at least a specified number of detail records fit into the remaining space. I hope this helps. Teodor
  3. Changed Resolution from Reopened to Fixed Changed Status from Feedback Requested to Resolved Hi,Feel free to reopen in case you still have this problem with the latest version and the provided solution.Thanks,Teodor
  4. Changed Resolution from Open to Fixed Changed Status from Confirmed to Resolved Hi,This is now fixed on the master branch of our Git repository and will be part of the next release.Bands with splitType="Prevent" will render on the current page/column if the page/column is already new and does not contain any element at the top, except for reprinted group headers.If a group has started at the top of the page/column and has printed some headers, that page/column is no longer new and a break would normally occur, as we hope that on the new page/column there will be more space available and thus the break make sense.JRL project now contains a lot of test cases in the /tests folder of the project source distro which help document how these features work and to detect possible regressions in the future, if something changes.Thanks,Teodor
  5. Changed Assigned User from @lucianc to @teodord Hi,We try to do something about this, but we need to make sure our proposed solution solves as many cases as possible, without too much regressions.We all agree that a band starting on a new page/column should not be moved onto next page/column when splitType="Prevent", because on the next page/column it is likely that there will be the same amount of available space and this creates an almost empty page/column for nothing.The most complicated thing here is to define the criteria for declaring that a page/column is new.It is obvious that on a page/column on which only page/column header section was rendered can be considered new.But what about a page column where a group starts and renders several levels of group headers. With all these group headers rendered at the top, is the page/column still new?The splitType attribute is not specific only to the detail bands. It can also be set to group header bands. So should a group header with splitType="Prevent" be kept on current page/column if above it are only group headers? Note that on the next page/column, these group headers above would probably not appear, offering the non splitting header more space to render.One could argue that in this case, moving to next page/column is not totally non-sense, because there will indeed be more space available.It would be great if you guys could provide us your feedback and help us find the best solution to this problem.Thank you,Teodor
  6. Hi, Just to let you know that with the upcoming release, the newly introduced minDetailsToStartFromTop property added to groups, would cause the group to start on a new page/column even if the current page/column is new, as it is the case at the start of subreports. Basically, setting a value hight enough for minDetailsToStartFromTop, would cause it to work more like keepTogether, except the break will occur every time the condition is not met, including page/columns that are already new. I hope this helps. Teodor
  7. Hi, The SF.net based Maven repository you mentioned is now somewhat deprecated and no longer updated. We instead use this newer repository for JRLib dependencies: http://jaspersoft.jfrog.io/jaspersoft/third-party-ce-artifacts/ I hope this helps. Teodor
  8. Changed Resolution from Open to No Change Required Changed Status from Feedback Requested to Resolved Hi,I think that triggering the caching of the data on the first pass using a sort field based on the REPORT_COUNT built-in variable, so that the original order of the records is not affected, would be enough to perform complex calculations and direct data access on the SortedDataSource object.Using an utility class to leverage the API which has SortedDataSource object at the top should be a fairly simple way to achieve any kind of data processing during report execution.So I'm closing this one now.Thanks,Teodor
  9. Changed Status from New to Feedback Requested Changed Assigned User from - to @teodord Hi,The use of SortedDataSource internally in the JR engine is only triggered when sort fields are used, which means the data is cached on first pass.But if there is no sort field defined in the dataset, JR will not cache and will not sort anything, which means it will not consume memory unnecessary.I mention this because you said JR already has all the information needed. It has it, but only under certain circumstances and the report creator needs to understand the implications when using the feature.Thank you,Teodor
  10. Changed Resolution from Works as Designed to Fixed Changed Status from New to Resolved Changed Assigned User from @alex to @teodord Hi,@helois, the NullPointerException was reported also on this tracker:https://community.jaspersoft.com/jasperreports-library/issues/8671and was fixed in release 6.4.1.Thanks,Teodor
  11. Changed Resolution from Open to No Change Required Changed Status from Feedback Requested to Closed
  12. Changed Resolution from Open to No Change Required Changed Status from Feedback Requested to Closed
  13. Changed Resolution from Open to Fixed Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi,This is now fixed for PPTX and XLSX for the upcoming release. The formerly deprecated JExelApi exporter will be completely removed.Thanks,Teodor
  14. Changed Resolution from Open to Fixed Changed Status from Feedback Requested to Resolved Hi,Here's what could be a conclusion for this tracker:1) In JRLib, URL redirect works automatically, because this is a feature of the Java networking API behind the scenes.In the provided example, it does not work in one case, which is about a redirect that involves a protocol change from HTTP to HTTPS, which is not supported by the Java SDK automatically.They explained their reasons here:http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4620571I quote: "After discussion among Java Networking engineers, it is felt that we shouldn't automatically follow redirect from one protocol to another, for instance, from http to https and vise versa, doing so may have serious security consequences. Thus the fix is to return the server responses for redirect. Check response code and Location header field value for redirect information. It's the application's responsibility to follow the redirect."Supporting redirects that involve protocol change would require us to handle these redirects in our JRLib code, and for now we don't want to take this path.Maybe you can avoid this by using HTTPS in the initial URL, so that no protocol change occurs during redirect. Or you can implement your own image utility to deal with these redirects the way you already attempted.2) There was this issue in JRLib with regards to the fact that the onErrorType property was not honoured when the exception occurred during expression evaluation. It was honoured only when image data was processed (later). We fixed this issue for the upcoming release, so I think we can consider this matter closed now.Thanks,Teodor
  15. Changed Status from New to Feedback Requested Hi,If you could show us a model of the document you need to produce, maybe we can suggest a workaround.Maybe a crosstab or a horizontal list component would help.Thanks,Teodor
  16. Changed Status from New to Feedback Requested Changed Assigned User from - to @teodord Hi,We are talking about a quite old version of JR Lib (3.0?), in which case there is nothing we can do about.But it would help explain what you see if you could provide a simple report and some resulting XLS files to be able to see the problem on our side.Thanks,Teodor
  17. Changed Status from New to Feedback Requested Changed Assigned User from - to @teodord Hi,It would be good to see some JRXML files and some resulting PDFs to be able to figure out what the problem is.The short paragraph in which you described the problem clearly indicates that the report design is quite complex and would probably be hard to reproduce the problem on our side, using only this information.We have recently committed several bug fixes and improvements related to the "Keep Together" feature of groups and hopefully they would cover your case too.The changes are on the master branch of our Git repository and will be part of the next release.Thank you,Teodor
  18. Changed Resolution from Open to No Change Required Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi, RobertThis is actually a case of bad naming that is more like a historical relic in JR Lib.Although the property is called minHeightToStartNewPage, it actually behaves like minHeightToStartNewColumn.Maybe in a future release, we'll deprecate it and create a new one with the correct name, while keeping backwards compatibility of report templates.Thanks,Teodor
  19. Changed Resolution from Open to Fixed Changed Status from Assigned to Resolved Changed Assigned User from @tkavanagh to @teodord Hi,This can be done using the "com.jaspersoft.jrs.data.source" custom property in the subreport dataset, to point to a different data source, as explained here:http://community.jaspersoft.com/wiki/how-deploy-reports-tibco-jasperreports-server-subreports-use-different-data-sourcesI hope this helps.Teodor
  20. Changed Resolution from Open to Fixed Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi,This is now fixed on the master branch of our Git repository and will be available with the next release.Thanks,Teodor
  21. Changed Resolution from Open to Fixed Changed Status from Acknowledged to Resolved Changed Assigned User from @lucianc to @teodord Hi,In version 6.3.1, we added support for custom property expressions at dataset field level, which deprecates the use if fieldDescription in data sources and query executer implementations.Thank you,Teodor
  22. Hi, Let's first clarify what we are currently dealing with: #1 We did not do anything yet to support URL redirect for images. Even if you use the latest JR release, the redirect would not work. So let's put aside the redirect problem for the moment. You said you devised your own way to perform redirects, so I assume you'll stick to that for now. #2 I took JR release 6.3.0 project and put your redirect.jrxml file in place of the /demo/samples/images/reports/ImagesReport.jrxml file. I also modified the internal name attribute to change it to name="ImagesReport" in the JRXML. I then ran the sample normally using ">ant clean javac compile fill" from command line. The fill process went without error. This is because although you did not specify any onErrorType for your images, and the default is "Error", the image elements also have scaleImage="RetainShape" by default. This means the program does not attempt to load the image during fill, because it does not need to check the size of the image. The size of the image will only be needed at export time. During fill, the image files will be grabbed from the remote location and stored in the generated JasperPrint object (*.jrprint file). You can see this by exporting the filled report to XML using ">ant xml" command in the sample folder. It will produce a folder under /demo/samples/images/build/reports/ImagesReport.jrpxml_files with 3 image files in it, the third one being of size 0 bytes. Now, if you try export to any format such as PDF, HTML or if you try view the report with the Swing viewer using ">ant view", you'll get an error because the third image with 0 bytes is invalid and an exception is raise because of the onErrorType="Error" mentioned above. However, if you modify your report and put onErrorType="Blank" or onErrorType="Icon" for your 3 image elements in the JRXML, you'll see that exporting or viewing the report no longer raises any error and you either see blank or the generic icon for the 3rd image. What exactly you think is wrong with the way this report you sent us works? Thanks, Teodor
  23. It has been found that the PhantomJS process used to render HTML5 Charts and Charts Pro elements on the server side interferes with browser HTTP persistent connections when using Tomcat on Windows. The symptoms of the problem are the following: after an export of a report that has HTML5 Charts or Charts Pro elements is launched, browser requests made on previously established HTTP connections can block for up to a few minutes (that is the server does not return any data and the browser waits for a response until the request times out). From a user perspective, the TIBCO JasperReports® Server UI appears unresponsive to actions like button and menu clicks or URL accesses. The problem occurs then the APR/native HTTP connector is used in Tomcat (which is the case by default in Windows). It has been observed on a Windows 8.1 machine, and it might affect JasperReports® Server deployments on other Windows systems. The source of the problem seems to be the fact that when the Tomcat Java process launches a child PhantomJS process, sockets created by the APR connector are inherited by the child process and made unusable for the Tomcat process. A workaround for the issue is to comment the net.sf.jasperreports.phantomjs.executable.path property in WEB-INF/lib/jasperreports.properties, and to use com.jaspersoft.jasperreports.highcharts.phantomjs.executable.path and com.jaspersoft.jasperreports.fusion.phantomjs.executable.path instead (as in JasperReports Server 6.3.0). With PhantomJS configured as in 6.3.0, PhantomJS processes are still launched but the processes are generally short lived, therefore the chances of users encountering the problem are much lower. Another way to avoid the problem is to change the HTTP connector implementation in Tomcat to one of the Java IO implementations. Deploying JasperReports Sever in a Tomcat instance that does not use the default HTTP connector implementation has not been thoroughly tested though and could have unwanted consequences.
  24. Hi, You are probably aware that after version 2.1.7, iText has changed its open source license and can no longer be used in commercial applications. We cannot use newer iText version with our open source project because the new iText license would not allow it to be used everywhere JR Lib can be used. Most likely you need a commercial license from iText, and in that case, you would also need to create a PDF exporter for JR Lib, based on that new version of iText. I hope this helps. Teodor
  25. Hi, Can you confirm you are using JR 6.3.1 with this modified code to support the redirect? Thanks, Teodor
×
×
  • Create New...