darth_fader

Thank you for the quick response! I appreciate it. And I may have reached out prematurely - I'm not crazy about having to use the keystore but really it's not that involved to set up, and I understand why it's been put in place.

Is it possible to disable the JasperServer 7.5 Encryption/Keystore behavior around server archive exports? This is creating allot of overhead for clustered deployments, and requires copying/pasting keystore files for consistency. It would be preferable to disable that altogether so in this aspect JasperServer behaves like older versions. Ideally, this would be doable via configuration only - without having to create a custom JasperServer build. I also think it's better to provide the flexibility and make it the default behavior than to make it required behavior. This may be best practice by TIBCO standards, but copying/pasting keystore files to support clustered deployments definitley is not . Please let me know if this is possible, and if so where I might find the supporting documentation. Thanks!

The recommended fix in the wiki is to add the following property to each text field in the detail band - <property name="net.sf.jasperreports.export.xls.auto.fit.row" value="true"/> https://community.jaspersoft.com/wiki/how-expand-excel-cell-height-dynamically I tested that out, works pretty well - see the attached file. Might be a way to do this on a group basis by adding those text fields to an element group or frame, didn't test that out.

Are these DB connections configured in JasperStudio or JasperServer (or both)? It seems you need to add the MS SQL Server JDBC Jar lib in studio via Preferences - > Java -> Build Path -> User Libraries. MS SQL Server DB connections typically require this addition. I know I've had to add that JDBC Jar directly many times over. If this doesn't work let me know, just post back any supplemental info you can.

If you use the standard approach of <connectionExpression><![CDATA[$P{REPORT_CONNECTION}]]></connectionExpression> in your subreport reference configuration, that $P{REPORT_CONNECTION} is the datasource of the parent report. So what you're asking about is the default behavior. By default, if you pass that $P{REPORT_CONNECTION} as the connection expression, it will use whatever the parent report is using. In terms of supporting 14 databases dynamically, there are definitely ways this can be done, but they're fairly advanced configurations. If you're not seeing the subreport being populated on JasperServer, JasperStudio may not be able to find it when you initially publish the parent report. If you're publsihing these via studio, during the 'create server report' wizard, you'll see any/all of the resources being promoted as part of the report unit. If these aren't getting published at that point, it's typically due to the subreport 'path to file'. You can always add subreports directly on jasper server via the 'edit report' options, but you may also need to update the 'path to file' to reflect 'repo:subreportName.jrxml' and so on.

Minor note - if you're hosting these reports on jasper server, you'll need to set the 'language' attribute on the <queryString> element to 'plsql' to support the 'call' keyword, so <queryString language="plsql"; alternatively you can change the sql validator on the properties file on jasper. If the 'langauge="plsql" approach doesn't work, look into the validator.

FYI You should be able to install JDK 8 alongside 9 and point studio to use 8, Preferences -> Java -> Build Path. You can have multiple JDKs on the same os.

This deprecation started on JDK V9. JasperReports library (and JasperServer) are compatible with specific versions of Java, and so if you compiled the report in JDK 8 you'd eliminate this issue. Potential solutions include: 1. install JDK 8 and configuring your environment to use that rather than 13 2. update the version of JasperReports/Server you're using - assuming the latest libraries are compatible with JDK 13, I'm a few versions behind and so I'm not sure what's compatible with what 3. ignore it for now - this type of deprecated functionality is not likely to cause problems - that type of casting is so widely used, and the integer functionality so basic, that you likely won't have any problems with this. If your project can't tolerate these warnings, you'll have to work through one of the first two options.

Regarding the extra blank page from your #1 approach - you may need to remove extra white space in your bands and double check to ensure you don't have any 'extra'/empty bands defined with any height. That 'extra' white space is frequently the cause of the extra-blank-page problem. For instance, if you used the 'create new report' wizard in studio, you'll get an empty, yet height-defined/present summary band'. If you've already addressed 'extra' empty bands and whitespace without success, if you add your JRXML I will review. Good luck!

Yes, but not in an automatic way - you'll need to add a link to your report output that will open the same report in another tab using the hyperlink component. Hozawa describes that 'open in a new tab' functionality here - https://community.jaspersoft.com/questions/912346/drill-down-detail-report-open-new-tabwindow With this, you'd just have to click the link to see the report in another tab. The only way to do what you're proposing without that extra 'link' step would be to customize jasper server and build from source, which for this use case I wouldn't recommend. More info on hyperlink behavior is available in the official schema. Good luck! https://jasperreports.sourceforge.net/schema.reference.html#hyperlinkAnchorExpression

Found some info that may help, these links will show you how to enable logging to see the 'offending' JARs and how to 'skip' scanning them on startup - if that's in fact the issue here. I would double check to see that the user starting up jasper has full admin access on all tomcat/jasper directories too. https://community.jaspersoft.com/wiki/least-one-jar-was-scanned-tlds-message-server-start https://stackoverflow.com/questions/40204124/how-to-fix-jars-that-were-scanned-but-no-tlds-were-found-in-them-in-tomcat-9

correction *page break between the two lists (break element in studio)

I suggest using two list components, the first list on page one, the second on page two, with a line break in between the two lists. Pass a parameter into the list dataset that will know which of those fifty to return, i.e. how to limit the queries results to return the 20 or 30 rows, depending on which list is being populated. HYow you implement that portion will depend on the datasource type, and if it's SQL, the specific database vendor. (LIMIT, OFFSET, TOP) etc.

The short answer is no - the height/width properties of the rectangle element are static in the JRXML, they cannot change at report runtime. However, there are chart types that can generate something very similar, the immediate one that comes to mind is the stacked bar chart. The highcharts (premium) version can give you something very close to what you're trying to do. The free jasper version can generate the bar, but I'm not sure about the overlaying %s. Your options here are based on whether or not you have a Tibco license to use the premium chart types.

There isn't enough memory allocated to the JVM to process that much data; jasper is failing because it doesn't have the resources needed to fill that report. If this is happening on your local machine, you can increase the memory available to the JVM, but that will be limited by the system you're using (the actual memory available). https://www.messiahpsychoanalyst.org/wikihow/index.php/How_to_Increase_Java_Memory_in_Windows If this is happening on JasperServer, you have several options available to address this, but the most straight forward is again to increase the memory available. You can find documentation on the Apache Tomcat website, and here's an example that demonstrates how that's done https://helicaltech.com/how-to-configure-jasper-apache-tomcats-java-heap-size/ If increasing the memory available the JVM isn't an option, you can look into virtualizers, which can help segment the amount of memory in use - if so just post back, that's a bit more involved than just bumping up the memory settings - https://helicaltech.com/usage-virtualizers-jasperserver/

You can validate the parameter values - so if the range is larger than 90 days, set another param value so that the SQL doesn't execute. i.e. is. dateParam2- dateParam1 > 90 days? then setValueToPreventQuery (SELECT 1 WHERE false etc) Alternatively, you could simply default to 90 if those values are greater than 90, and just display a msg to the user - "your inputs where greater than 90 days apart,, so here's the 90days starting with X". What I typically do is render a link for direct file download - prevents so much system churn etc. Sometimes a user might need more than 90 days. If a direct file download isn't feasible, maybe schedule the report for off-peak execution. Many different ways to approach this. JasperServer doesn't provide for sophisticated input validation - you can customize but if you're just figuring this much out, I would suggest custom input controls.

Patches have been released, FYI. Thank you TIBCO/Jasper Dev Team! https://www.tibco.com/support/notices/2021/12/apache-log4j-vulnerability-update

FYI, simply replacing 2.16.0 with 2.17.0 results in the following: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. SLF4J Error Codes Which equates to no logging. So we're just going to wait for an official patch and hope for the best.

Tibco, A new log4j vulernability has been identified, CVE-2021-45105, and the issue is resolved in log4j 2.17.0. Are there any plans to release a hotfix/patch to address this new vulernability? The latest hotfix for enterprise licenses doesn't address this vulnerability. In the mean time we're going to try upgrading manually to log4j 2.17.0, but as enterprise licensees, we'd prefer an official patch from Tibco. And thank you all for being so responsive around these issues, I know there are a number of TIBCO java based products impacted.

Jacquie did you receive a direct notification on that? An email or some notice in the premium portal? I didn't receive anything. Definitely didn't see it and they're not including that on their support public notices. Thank you for sharing that solution!

I've posted another question just to call this out directly (again) - 4 days of TIBCO working on resolutions, without so much as a mention of Jasper - not for community or enterprise.

Curious when TIBCO plans to address the log4j vulnerability for jasper server? Haven't seen anything in the community or the premium portal. We're running 7.5.x Enterprise, and resolving this should be as simple as upgrading log4j from the supplied 2.12.1 (vulnerable) to 2.15 (not vulnerable). But because it's an Enterprise license, we're waiting on an official patch. Any estimates? I haven't seen or heard anything from TIBCO about addressing this for Jasper, and it's been several days since fixes were released for other TIBCO products. Four days of postings with no mention of Jasper: https://www.tibco.com/services/support/public-notices

You'll need two text fields in each crosstab data cell (laying one on top of the other - same size and x/y coordinates) - one with left aligned text for numbers, one with right aligned text for strings. Then use printWhen expressions with some form of 'is numeric' test to determine which to use for each value to display. There are many different ways to perform the 'is numeric' test available.

You need to save your ad-hoc view as a report, and then use visualize js to display that report in angular. Visualize.js is an easy to use, javascript API specifically for embedding jasper server resources into web applications. There are a number of tutorials and 'how to' guides on these topics.

This may well be an issue with scope/context - I don't think there's any readily available means to refresh a data set from within the context of a report. Without that, I don't think what you describe is feasible. What I'd consider is having some type of custom event sequencer such as: 1) run report 2) run javascript to update DB 3) run report again if data changed If you're using javascript to interact with the DB, you can also use it to create the suggested sequence as a whole, assuming you're displaying this in a standard web page etc. A sequence of event handlers should do the trick.