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

vchiem

Members
  • Posts

    443
  • Joined

  • Last visited

 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 vchiem

  1. please refer to: https://community.jaspersoft.com/wiki/kspath-entry-jrsksp-file-no-longer-exists-tibco-jasperreports-server-78
  2. Issue:In JasperReports® Server 7.5, there was a requirement to update the keystore files as documented in the article "Encryption in JasperReports Server 7.5+" (see Related Article section). The specific section of the article is "Updating Keystore files" which details steps to base64 decode the .jrsksp file, modify the ksPath property and base64 encode the file back. However, in JasperReports® Server 7.8, the ksPath no longer exists as a property. What is the reason for this and is it still required to update the keystore properties file ? Solution: The ksPath was there in the .jrsksp file when the enhanced security encryption of keys started in JasperReports® Server 7.5. But from JasperReports® Server 7.8+, Jaspersoft Engineering decided to make configuration of keystore files location easier by eliminating it from the .jrsksp property file. The updating of the keystore files location by manually doing a base64 decoding and encoding of the .jrsksp is no longer necessary. The user can update the WEB-INF/classes/keystore.init.properties and set "ks" and "ksp" to a different path and then relocate the keystore files to this path having the appropriate directory permissions for the user account. The order of inspection of the keystore files location remain the same as documented in the above referred article : - “ks” and “ksp” environment variables - WEB-INF/classes/keystore.init.properties: ks, ksp properties Typically the keystore files are stored in the user's home directory. Note that modifying the keystore.init.properties requires a restart the JasperReports application server. Related Articles:https://community.jaspersoft.com/wiki/encryption-jasperreports-server-75
  3. Issue:In TIBCO JasperReports® Server, the report can be previewed and exported to PDF successfully in a new browser tab (URL: https://server:port/jasperserver-pro/flow.html/flowFile/<report>.pdf). From this browser tab, the downloading of the PDF report fails with the error "Failed - Network error" or "Failed - Server Problem". The browser page then displays the following: Error MessageAn id is required to lookup a FlowDefinition (Error UID: 5b0e7de7-3bd9-4b4b-8e2f-16aee6610d43)Error Tracejava.lang.IllegalArgumentException: An id is required to lookup a FlowDefinition at org.springframework.util.Assert.hasText(Assert.java:181) at org.springframework.webflow.definition.registry.FlowDefinitionRegistryImpl.getFlowDefinition(FlowDefinitionRegistryImpl.java:55) ... ...[/code] The issue was observed using Chrome and Edge browsers but not Firefox where the PDF download was successful. Solution:TIBCO JasperReports® Server is responsible for the generating of the PDF report but the downloading of the generated PDF report is performed by the browser. Given that the PDF download failed with Chrome (and Edge) and not Firefox may be caused by chromium-based browsers and its internal PDF viewer. The following are possible options the user can take to workaround this problem : 1> In the browser tab of the generated PDF, first click on "Print" and then "Save As PDF" option. 2> Enable pop-up download prompt to change the default behavior of opening in a new Chrome tab. In the Chrome browser, go to : Settings -> Privacy and security -> Additional content settings -> PDF documents and change the default behaviour from "Open PDFs in Chrome" to "Download PDFs" 3> Install a different PDF viewer as an alternative to the built-in PDF viewer (such as Adobe Acrobat Reader chrome extension) Note: The behavior changed in TIBCO JasperReports® Server 7.9 where it automatically generates a pop-up download prompt for the user to save the PDF to the local drive upon exporting the report to PDF. Related Articles:https://superuser.com/questions/1041849/failed-server-problem-when-trying-to-save-a-pdf-in-preview-in-google-chrome
  4. Issue:When a user tries to create a new instance using the AMI provided for TIBCO JasperReports® Server version 7.5.x and this instance is launched, the following errors were observed during the deployment as captured in the catalina log : [toc]16-Sep-2021 00:37:11.010 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/8.5.69]16-Sep-2021 00:37:11.063 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/var/lib/tomcat8/webapps/jasperserver-pro]16-Sep-2021 00:37:41.631 SEVERE [localhost-startStop-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [standardEngine[Catalina].StandardHost[localhost].StandardContext[/jasperserver-pro]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:755) ... Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -28 at java.lang.String.substring(String.java:1931) at org.apache.catalina.webresources.DirResourceSet.listWebAppPaths(DirResourceSet.java:175) at org.apache.catalina.webresources.StandardRoot.listWebAppPaths(StandardRoot.java:148) ...[/code]The Tomcat server failed to start successfully and users are unable to access the TIBCO JasperReports® Server login page. Solution:For TIBCO Jaspersoft® for AWS 7.5.*, the default version of installed Tomcat is 8.5.51. Amazon marked this version as a security vulnerable and added 8.5.69 in the AWS repository. When a user launches the instance on AWS, AWS checks the installed packages for vulnerabilities and if any is found, those packages will be updated. In this case, the Tomcat version is getting updated to the latest available version of 8.5 which is currently 8.5.69. However, this particular Tomcat version has a regression defect causing the above described issue. The specific regression in Tomcat 8.5.69 is: Bug 65397 - NullPointerException during jar scanning with jar symlinked into WEB-INF/libwhich is subsequently fixed in 8.5.70 onwards through the following bug : Bug 65433 - Possible StringIndexOutOfBoundsException for symlinks in DirResourceSet.listWebAppPaths "Correct a regression in the fix for 65397 where a StringIndexOutOfBoundsException could be triggered if the canonical path of the target of a symlink was shorter than the canonical path of the directory in which the symlink had been created. Patch provided by Cedomir Igaly. (markt)" Upgrading to Tomcat 8.5.70+ is a possible workaround option but taking into consideration that this version is not currently available in the AWS repository, it would require more manual steps to download the version directly from Apache website prior to installing. Instead, TIBCO Engineering has decided on planning to update the 7.5.x AMIs with a previous release of Tomcat 8.5.63 which does not seem to be marked for security vulnerability by Amazon. Until the AMIs are updated, the recommendation is to follow the workaround below to manually downgrade Tomcat to 8.5.63 which will bring the version of Tomcat in-line with the version that is planned. Workaround:Important: Take a backup of Tomcat and the Database Option 1. Manually remove tomcat 8.5.69 and install 8.5.63ssh into the instance and run the commands below: sudo suservice tomcat8 stop && yum erase tomcat8* -y && yum install tomcat8-8.5.63-1.87.amzn1.noarch -y && cat /etc/jasperserver/tomcat8.config >> /etc/tomcat8/tomcat8.conf && sed -i 's/8080/80/g' /etc/tomcat8/server.xml && sed -i 's~TOMCAT_SCRIPT="/usr/sbin/tomcat8"TOMCAT_SCRIPT="exec /usr/local/bin/authbind --deep /usr/sbin/tomcat8"' /etc/init.d/tomcat8 && chown -R tomcat:tomcat /usr/share/tomcat8 && chown -R tomcat:tomcat /var/lib/tomcat8 && chkconfig --add tomcat8 && chkconfig tomcat8 on && service tomcat8 start[/code]Option 2. If using the Cloud Formation Template (CFT) for deploymentUpdate the template with two changes as highlighted in the screenshots below: Image 1: Image 2:Note: The changes should work for Byol, Hourly or MT Hourly templates. Please find attached the BYOL Cluster Template for reference. Related Articles:https://bz.apache.org/bugzilla/show_bug.cgi?id=65433https://bz.apache.org/bugzilla/show_bug.cgi?id=65397
  5. Issue:After upgrading TIBCO JasperReports® Server from version 7.5 to version 7.9, custom holiday exclusion calendars that were created in the previous version no longer appears in the Holidays drop-down list. All that is available in the Holidays dropdown list are the defaults listed, 'None' and 'New Years Days' as shown: Due to this issue, upgraded scheduled jobs were no longer associated to the custom holiday exclusion calendars. Solution:The TIBCO JasperReports® Server 7.9 upgrade has resulted in the qrtz_calendars table updated with scheduler server instance name being "JasperServerScheduler" running on the actual server instance/node. In the previous version the server instance name was "quartzScheduler" and custom holiday exclusion calendars were created with this former name. The only calendar entry that appears in the Holidays dropdown list is the "New Years Days" because it is the only entry having a scheduler server name of "JasperServerScheduler". Use a database query tool to connect to the jasperserver repository database and perform the following checks: 1> Query the qrtz_scheduler_state table for which scheduler server instance is running on the right server host. select * from qrtz_scheduler_state;[/code]and determine the sched_name running on the instance_name matching the server host. The expectation is that the sched_name is "JasperServerScheduler" and the instance_name contains the actual server host name. There may also be another entry where the sched_name is "quartzScheduler" with the instance_name referring to a server host name that may be the same or different as the actual server host name as it is an entry that came from the pre-upgraded version. 2> Query the qrtz_calendars table in the jasperserver repository database : select * from qrtz_calendars;[/code]After the upgrade, there is only one entry, "New Years Days", for the scheduler name of "JasperServerScheduler". The custom entries in this table exists but were migrated across with a scheduler name of "quartzScheduler" and despite the entries appearing in the table itself, they do not appear in the UI. Workaround: This issue was raised as a defect (refer to Related Articles section for incident details). Until there is a fix to the upgrade scripts, there are two workaround approaches to resolve this issue. 1> Use REST_v2 API to create/update the custom holiday calendars. This would be the same approach as how the custom calendars were created in the previous version since it is the only approach available to create/update custom calendars. For more information, refer to the calendars Service in the TIBCO JasperReports® Server REST API Reference guide : https://community.jaspersoft.com/documentation/tibco-jasperreports-server-rest-api-reference/v790/calendars-service This approach will create additional entries in the qrtz_calendars table with reference to "JasperServerScheduler" as the scheduler name. Note: This is the supported/recommended method since it does not entail manual backend update modification of repository metadata. 2> Backend table update method This is a method which involves a sql update and such method should be tested in a Test/Dev environment first. i> BACKUP table qrtz_calendars (IMPORTANT step in-case of user errors and to keep a record of pre-modification state) ii> Update custom holiday exclusion calendars to reference the correct scheduler server name : update qrtz_calendarsset sched_name='JasperServerScheduler'where calendar_name='<custom calendar name>';[/code]iii> As a verification check, re-visit the Schedules page via the UI or even create a new schedule. You should now see the custom holiday exclusion calendar entry in the Holiday drop-down list. iv> Repeat step ii> for any other custom holiday calendars Note: You would have identified all the custom calendar names (which has sched_name="quartzScheduler") from querying the qrtz_calendars table step above. As a summary, the solution is to ensure the custom holiday calendars have the correct scheduler server name data in the qrtz_calendars table so that they appear in the Holiday dropdown list in the UI. Doing this will subsequently allow any existing scheduled jobs to be able to "associate" to the now existing custom holiday calendar. These existing scheduled jobs would have already have the association defined in the table column JIReportjobtrigger.calendar_name. Related Articles: JS-62853: After upgrade custom holiday calendars no longer appear in the Holiday drop down list
  6. Issue:The issue described here occurs on a Windows Server environment where TIBCO JasperReports® Server was configured to use Chrome.exe for rendering of reports containing Charts. Exporting a report that contains 4 or more charts to PDF format fails with the following page display : There was an error on the server. Try again or contact site administrators. (Error UID: a184e986-6a66-4c35-9458-bcc26e4f7670)[/code]and the underlying exception when checked against the jasperserver.log file is: 2021-08-10T10:49:55,612 ERROR ErrorPageHandlerAction,https-jsse-nio-443-exec-4:118 - Error UID a184e986-6a66-4c35-9458-bcc26e4f7670 net.sf.jasperreports.engine.JRRuntimeException: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: Failed sending HTTP request. at com.jaspersoft.jasperreports.highcharts.charts.ChartPdfHandler.exportElement(ChartPdfHandler.java:45) at net.sf.jasperreports.engine.export.JRPdfExporter.exportGenericElement(JRPdfExporter.java:4141)...Caused by: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: Failed sending HTTP request. at com.github.kklisura.cdt.services.impl.ChromeServiceImpl.request(ChromeServiceImpl.java:292) ... 223 moreCaused by: java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method)[/code]The issue was not observed for reports containing up to 3 charts. Solution:This article references the supplementary article, Debugging Chrome/Chromium for graphical rendering of reports, to set additional debug options. With the additional debugging set, after reproducing the issue and checking the jasperserver.log at that point in time, there are more granular information captured which exposes the websocket port number used by Chrome.exe Example:2021-08-10T10:39:54,634 DEBUG WebSocketServiceImpl,pool-37-thread-1:113 - Sending message {"id":90,"method":"Runtime.awaitPromise","params":{"returnByValue":true,"generatePreview":false,"promiseObjectId":"2268887318714847274.2.1"}} on ws://localhost:64437/devtools/page/36F2E0695AC02705A8B4BE19407DD2A62021-08-10T10:49:55,611 ERROR SecureExceptionHandlerImpl,https-jsse-nio-443-exec-4:116 - There was an error on the server. Try again or contact site administrators. (Error UID: a184e986-6a66-4c35-9458-bcc26e4f7670)2021-08-10T10:49:55,612 ERROR ErrorPageHandlerAction,https-jsse-nio-443-exec-4:118 - Error UID a184e986-6a66-4c35-9458-bcc26e4f7670 net.sf.jasperreports.engine.JRRuntimeException: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: Failed sending HTTP request. at com.jaspersoft.jasperreports.highcharts.charts.ChartPdfHandler.exportElement(ChartPdfHandler.java:45)[/code]Note: This is not a fixed port number and can change (in the event where the chrome.exe process needs to be launched again) by the report export process. In this example, the websocket host and port that is trying to connect is localhost and 64437. Given that the cause of the exception as captured in the stack trace is: Caused by: java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method)[/code]This implies a network level connectivity issue trying to connect to the websocket host/port. The idea is to run a telnet command using a command prompt to test for the port running on localhost: telnet localhost 64437 Note: telnet client needs to be installed on the server for telnet command to work. If the telnet command fails to make the connection, the command will return the following message: Connecting To localhost...Could not open connection to the host, on port 64437: Connect failed A successful connection will just be a black/blank console output with no errors. The above test is a verification step to test for the websocket port and given that the error generated was "Connection refused: connect" we would expect the verification test to fail. For the port to be active, we would expect that the chrome.exe process remains in the background which can be checked in Task Manager (Processes tab) Workaround:The reason for the termination of the chrome.exe process (and hence the web socket port associated to the process) has yet to be confirmed. Whether it is environmentally related to a third party security application running in the background or certain firewall rules or even a Chrome behavioural issue with this specific version (92.0.4515.131) where it closes the process itself...is unknown. The TIBCO JasperReports® Server Administrator Guide explicitly states that chrome.path be set as following: chrome.path = C:/Program Files (x86)/Google/Chrome/Application/chrome.exe However, as stated in the documentation, chromium can also be used. The workaround is to use Chromium 79.0.3945 which has been tested against this issue successfully. Chromium builds can be downloaded the official site from the official site: https://www.chromium.org/getting-involved/download-chromium. Steps:Download and extract chrome-win.zip to c:chrome-win on the Windows ServerEdit .../WEB-INF/js.config.properties and set: chrome.path=c://chrome-win//chrome.exeRestart the application server Note: When downloading older versions of chromium via the section "Downloading old builds of Chrome / Chromium", the lookup base position number for Chromium version 79.0.3945.0 is 706915. Related Articles: https://community.jaspersoft.com/wiki/debugging-chromechromium-graphical-rendering-reports
  7. Issue:The TIBCO JasperReports® Server Administrator Guide documents the configuration required to use Chrome/Chromium for exporting graphical Chart reports and exporting dashboards. However there are no additional information on how to debug Chrome/Chromium whenever there are issues. What additional debugging can be performed to aid the user in circumstances where there are issues with exporting a Chart report (such as exporting to PDF format) or rendering of dashboards ? Solution: This article assumes that the TIBCO JasperReports® Server is properly configured to use Chrome/Chromium for Charts generation and exporting dashboards. If it is not yet configured, please refer to TIBCO JasperReports® Server Administrator Guide section "Configuring a JavaScript Engine for Graphical Report Rendering". 1> Checking the TIBCO JasperReports Server log file Whenever there are issues with exporting of a graphical chart report, the user may see an error displayed on the browser similar to: "There was an error on the server. Try again or contact site administrators. (Error UID: b3d56064-9574-4dac-9636-ffcb9d103384)" The error message is generic but there is a UID code that can be correlated to the same UID code in the jasperserver.log file. This is the main server log file that resides in the directory..WEB-INFlogs. Correlating the UID code in the log file can lead the user to the full stack trace such as below: 2021-08-06T07:10:50,105 ERROR ErrorPageHandlerAction,https-jsse-nio-443-exec-6:118 - Error UID b3d56064-9574-4dac-9636-ffcb9d103384 net.sf.jasperreports.engine.JRRuntimeException: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: <message of error> at com.jaspersoft.jasperreports.highcharts.charts.ChartPdfHandler.exportElement(ChartPdfHandler.java:45) at net.sf.jasperreports.engine.export.JRPdfExporter.exportGenericElement(JRPdfExporter.java:4141)...Caused by: com.github.kklisura.cdt.services.exceptions.ChromeServiceException: <message of caused by error>[/code]The error message in the "Caused by:" of the stack trace may be sufficient for the user to be able to determine the cause and thereby take the necessary actions to resolve the problem. 2> Setting additional logger components If the above check does not lead to a solution, then more granular information can be captured in the same jasperserver.log file. This can be done by adding the following logger components to DEBUG in the Server Settings -> Log Settings page of the TIBCO JasperReports® Server (logged in as 'superuser') : com.github.kklisura.cdt.launch = DEBUGcom.github.kklisura.cdt.services.impl = DEBUGnet.sf.jasperreports.chrome = DEBUG[/code]Note: This is an on-the-fly change that does not require a restart of the application server. Once these components are set, after reproducing the issue again, the jasperserver.log captures more verbose logging such as : 2021-08-10T14:45:28,284 DEBUG WebSocketServiceImpl,pool-14-thread-4:90 - Connecting to ws server ws://localhost:49312/devtools/page/644C28D808DF054A48FFCD4B6D66E6622021-08-10T14:45:28,366 INFO WebSocketServiceImpl,Grizzly(2):98 - Connected to ws server ws://localhost:49312/devtools/page/644C28D808DF054A48FFCD4B6D66E662[/code]The extra level of information is helpful as it exposes not just the events occurring but also the web socket port/s that is used for the report export since the port number can vary. Depending on what the actual error message is but the extra level of information can be the clue to pinpoint any server port restrictions involving firewall or third party security applications affecting the operations in the background. For example, the administrator may want to test the websocket port using "telnet localhost <port>" on the server to see whether the port is active. Aside from the websocket port/s, there are other events captured which can also be helpful in understanding the behaviour and hence the point of failure.
  8. Issue:For certain reports that was created in TIBCO Jaspersoft® Studio and published to the TIBCO JasperReports® Server, there is a failure when exporting to PDF format. The error that is displayed on the browser page is: There was an error on the server. Try again or contact site administrators. (Error UID: 7f214198-72c8-46e0-9fbf-85042cd192f9) and the jasperserver.log file captures the error "java.lang.IllegalArgumentException: path cannot be empty" : 2021-08-06T07:05:26,901 ERROR SecureExceptionHandlerImpl,https-jsse-nio-443-exec-9:116 - There was an error on the server. Try again or contact site administrators. (Error UID: 7f214198-72c8-46e0-9fbf-85042cd192f9)2021-08-06T07:05:26,902 ERROR ErrorPageHandlerAction,https-jsse-nio-443-exec-9:118 - Error UID 7f214198-72c8-46e0-9fbf-85042cd192f9 java.lang.IllegalArgumentException: path cannot be empty at com.jaspersoft.jasperserver.api.metadata.common.service.impl.hibernate.util.RepositoryUtils.resolveRelativePath(RepositoryUtils.java:138) at com.jaspersoft.jasperserver.api.engine.jasperreports.util.RepoRepositoryService.getInputStream(RepoRepositoryService.java:112) at net.sf.jasperreports.repo.StreamRepositoryService.getInputStream(StreamRepositoryService.java:43) at net.sf.jasperreports.repo.InputStreamPersistenceService.load(InputStreamPersistenceService.java:51) at net.sf.jasperreports.repo.InputStreamPersistenceService.load(InputStreamPersistenceService.java:41) at com.jaspersoft.jasperserver.api.engine.jasperreports.util.RepoRepositoryService.getResource(RepoRepositoryService.java:182) at net.sf.jasperreports.repo.RepositoryService.getResource(RepositoryService.java:50) at net.sf.jasperreports.repo.RepositoryUtil.findInputStream(RepositoryUtil.java:195) at net.sf.jasperreports.repo.RepositoryUtil.getBytesFromLocation(RepositoryUtil.java:211) at net.sf.jasperreports.engine.export.JRPdfExporter.getFont(JRPdfExporter.java:2749)[/code]Exporting the report/s to any other format works fine. Solution: The cause of the issue is a reference to a PDF Font that is invalid. In TIBCO Jaspersoft® Studio, navigate to the Source tab and search for any invalid entries relating to pdfFontName attribute. For example, the main report or subreport contains a style tag that has an empty reference to pdfFontName like this: <style mode="Opaque" forecolor="#FFFFFF" backcolor="#B42314" pdfFontName="">[/code]which is causing the "path cannot be empty" error. Remove this invalid entry and publish the report to the TIBCO JasperReports® Server before attempting an export of the report to PDF format.
  9. Issue:After executing ./js-install.sh (or js-install.bat) for installation of TIBCO JasperReports® Server version 7.9, plain-text passwords that were set in the configuration files were not encrypted after the installation. This is despite setting the propsToEncrypt property appropriately in the default_masters.properties file. As a use-case example, we have set the following : propsToEncrypt=dbPassword,external.dbPassword encrypt=true but after installation, the external.jdbc.password in the configuration file, js.externalAuth.properties, was not encrypted. In the previous version, TIBCO JasperReports® Server 7.5.1, we were getting encrypted passwords in the corresponding configuration files with the same default_master.properties settings. Solution:This is a regression defect that was reported for TIBCO JasperReports® Server versions 7.8 and 7.9 under the following incident reference: JS-59995: buildomatic does not encrypt more than one password at a time The defect is fixed for TIBCO JasperReports® Server 7.8 as a hotfix. To obtain this hotfix, download the latest 7.8 cumulative hotfix from Support Portal and apply the hotfix as per the instructions. Note: When reviewing the included readme.txt file, the reference incident will be listed as: "JS-59995 Update MasterPropertiesObfuscator to split propsToEncrypt by a comma" At this time of writing, the defect is formally fixed in the upcoming major release after TIBCO JasperReports® Server version 7.9 but there is no equivalent hotfix for TIBCO JasperReports® Server version 7.9. For users affected by this issue in TIBCO JasperReports® Server version 7.9, below are the steps to workaround this defect. Workaround for TIBCO JasperReports® Server version 7.9 only Before executing ./js-install.sh (or js-install.bat): 1> Edit default_master.properties file and only set one property to encrypt starting with dbPassword: propsToEncrypt=dbPasswordencrypt=true[/code]2> At the command line under buildomatic directory, run: cd <js-install>/buildomaticjs-ant clean-configjs-ant gen-config[/code]Note: The first js-ant command deletes all the files (and even default directory itself) in buildomatic/build_conf/default directory. The second re-builds the configuration settings and files are recreated in this directory. 3> Edit default_master.properties file and only set the next property to encrypt : propsToEncrypt=external.dbPasswordencrypt=true[/code]Important note: This file was changed from step 2 so that encrypt.done=true appears. This needs to be changed back into encrypt=true 4> At the command line under buildomatic directory, run: js-ant gen-config[/code]Note: do not run "js-ant clean-config" otherwise the first encrypted password will be invalidated. After performing the above steps, navigate to buildomatic/build_conf/default and check the following files to verify the passwords are encrypted: js.jdbc.properties - for validation of property dbPassword js.externalAuth.properties - for validation of property external.dbPassword Note: the default_master.properties file was updated as well to reflect on the encrypted passwords and encrypt=true becomes encrypt.done=true You can then execute ./js-install.sh to carry out the installation. Post-installation, you can check the context.xml under /META-INF and js.externalAuth.properties under ../WEB-INF directory for the above two encrypted passwords. Note: The workaround provides for a use-case where propsToEncrypt is set to two specific properties (dbPassword, external.dbPassword) but the workaround is applicable to all valid properties set as long as there are more than one properties set (which is what the issue was caused by). ref: 02042496
  10. Issue:We have followed Talend's documentation on "Enabling SSL for Nexus 3" but we are still unable to set this up successfully. What are the steps involved to enable SSL for Nexus 3 so that we can connect from TAC to Nexus Server using HTTPS connection ? Solution: For this scenario, the Nexus server resides on the same server as TAC and the Tomcat server was already set up with SSL. See Related Articles section below for a separate link to "How to enable HTTPS login for TAC" There are two phases: 1. Set up SSL for Nexus server and ensure the browser can log into Nexus server under the configured https port 8441 2. HTTPS connection from TAC to Nexus Server as specified in the Configuration Page Phase 1: Setting up Nexus Server for HTTPS Connection Steps:1. Copy the keystore file (custom named as TibcoKey.bin) from the Tomcat server/conf directory into the <installation_path>/tac/Artifact-Repository-Nexus-3.9.0-01-[OS]/nexus-3.9.0-01/etc/ssl folder2. Edit the <installation_path>/tac/Artifact-Repository-Nexus-3.9.0-01-[OS]/sonatype-work/nexus3/etc/nexus.properties file to add the ssl port and add the reference to the ssl configuration file (jetty-https.xml):# Jetty sectionapplication-port=8081application-port-ssl=8441application-host=0.0.0.0nexus-args=${jetty.etc}/jetty.xml,${jetty.etc}/jetty-http.xml,${jetty.etc}/jetty-https.xml,${jetty.etc}/jetty-requestlog.xmlnexus-context-path=/3. Edit the ssl configuration file <installation_path>/tac/Artifact-Repository-Nexus-3.9.0-01-win64/nexus-3.9.0-01/etc/jetty/jetty-https.xml for the certificate and password:<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory"><Set name="KeyStorePath"><Property name="ssl.etc"/>/TibcoKey.bin</Set><Set name="KeyStorePassword">Tibco123</Set><Set name="KeyManagerPassword">Tibco123</Set>Note: Remove default references to the TrustStore path and password4. Start Nexus and login using browser to Nexus HTTPS URL using SSL port.[/code] Phase 2: HTTPS connection from TAC to Nexus Server as specified in the Configuration Page Steps:1. In Tomcat bin directory edit setenv.sh:export JAVA_OPTS="$JAVA_OPTS -Djavax.net.debug=ssl-Djavax.net.ssl.trustStore=<tomcat>/conf/TibcoKey.bin-Djavax.net.ssl.trustStorePassword=Tibco123Note: the -Djavax.net.debug=ssl can be omitted unless you want to enable vebose debugging for SSL 2. Stop and Restart Tomcat and ensure it boots successfully.3. Login to TAC under https and go to Configuration page. Ensure the https Nexus URL and port is correctly specified and test the connection[/code]Related Articles: Enabling SSL for Nexus 3: https://help.talend.com/r/RSZ9cD4BsXjW~9P_jzXR_w/3n7LABLKHgbczuT~5M4OMA How to enable HTTPS login for JAC (TAC - Talend Administration Center): https://community.jaspersoft.com/wiki/how-enable-https-login-jac-tac-talend-administration-center
  11. Issue:When specifying a https connection url in Jaspersoft® ETL Studio, we are unable to successfully make the connection. What are the steps that are required to enable HTTPS connection in ETL Studio ? Solution:1> Download the rootca certificate (eg. Digicert.crt) from the server to the Studio client windows machine2> Copy the rootca certificate to %JAVA_HOME%jrelibsecurity3> Import the rootca certificate into the java truststore by running keytool :keytool -import -trustcacerts -alias root -file Digicert.crt -keystore cacerts4> Edit the Studio_home/JETL-win-x86_64.ini file and add the following Java flags:-Djavax.net.ssl.trustStore=<complete path to truststore file cacerts>-Djavax.net.ssl.trustStorePassword=changeit5> Restart Studio and test the HTTPS connection[/code] Additional Notes: Should the following SSL error occur upon testing the connection : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target[/code]Then refer to the following article for solution: How to solve PKIX error when Studio connects to Talend Cloud: https://community.talend.com/s/article/How-to-solve-PKIX-error-when-Studio-connects-to-Talend-Cloud-Lw4Aw?language=en_US If further SSL debugging is required, the following article describes steps to collect debug traces for Studio connection: How to collect debug traces for Studio connection to Talend Cloud SSL: https://community.talend.com/s/article/How-to-collect-debug-traces-for-Studio-connection-to-Talend-Cloud-SSL-d1n43
  12. Issue: What are the steps involved to enable HTTPS / SSL for Talend Administration Center (TAC) ? Solution:Enabling HTTPS for TAC is essentially enabling HTTPS for Tomcat as TAC is a web application deployed on Tomcat. For Tomcat 9.0, refer to the following Tomcat documentation to create keystore and import trusted rootca or chain certificate (root and intermediate) and server certificate into the keystore: https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Configuration Modify Tomcat server.xml (under $CATALINA_BASE/conf directory) and change the connector for 8443 to point to the keystore. Example format: <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 --><Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile="${user.home}/.keystore" keystorePass="changeit" clientAuth="false" sslProtocol="TLS"/>[/code]Note 1: Ensure port 8443 is not blocked by the system firewall. Note 2: If the server certificate was imported with a 'trustedCertentry' entry in the keystore then it means that it is being treated as a root authority certificate which is incorrect. The server certificate must be imported as a 'privatekeyentry' entry. If such is the situation, please refer to extra steps below which is to generate bundle (.p12 file) from your private key and certificates. i> execute:openssl pkcs12 -export -in servercert.crt -inkey privateKey.key -name hostname -out filename-new-PKCS-12.p12ii> then add the bundle file (.p12 file) to keystore by executing the following command:keytool -importkeystore -deststorepass [password] -destkeystore [filename-new-keystore.jks]Example:keytool -importkeystore -deststorepass Tibco123 -destkeystore tiboKey.bin -srckeystore filename-new-PKCS-12.p12 -srcstoretype PKCS12Note 3: refer to article: https://stackoverflow.com/questions/24974324/import-certificate-as-privatekeyentry for more information [/code]Related Articles: How to configure Talend Services to use SSL: https://community.talend.com/s/article/How-to-configure-Talend-Services-to-use-SSL-UM3Wt?language=en_US
  13. Issue:After upgrading to Java 1.8.0_292 (or Java 11.0.11), the following exceptions were recorded in the Tomcat server log (catalina.out) upon start up resulting in the TIBCO JasperReports® Server application not working. Java versions prior to 1.8.0_292 and 11.0.11 do not encounter this issue. 21-Jun-2021 11:53:48.272 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[HTTP/1.1-7091]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1041) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) ... ... Caused by: java.lang.IllegalArgumentException: Key protection algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private Key failed: unrecognized algorithm name: PBEWithSHA1AndDESede at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:216) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1154) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1038) ... 13 more Caused by: java.security.KeyStoreException: Key protection algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private Key failed: unrecognized algorithm name: PBEWithSHA1AndDESede at sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:677) at sun.security.pkcs12.PKCS12KeyStore.engineSetKeyEntry(PKCS12KeyStore.java:577) at java.security.KeyStore.setKeyEntry(KeyStore.java:1140) at org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:357) at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97) ... 20 more Caused by: java.security.UnrecoverableKeyException: Encrypt Private Key failed: unrecognized algorithm name: PBEWithSHA1AndDESede at sun.security.pkcs12.PKCS12KeyStore.encryptPrivateKey(PKCS12KeyStore.java:921) at sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:614) ... 25 more Caused by: java.security.NoSuchAlgorithmException: unrecognized algorithm name: PBEWithSHA1AndDESede at sun.security.x509.AlgorithmId.get(AlgorithmId.java:448) at sun.security.pkcs12.PKCS12KeyStore.mapPBEAlgorithmToOID(PKCS12KeyStore.java:938) at sun.security.pkcs12.PKCS12KeyStore.encryptPrivateKey(PKCS12KeyStore.java:895) ... 26 more[/code] Solution:This was reported as a JDK bug external to the Jaspersoft application. The defect incident logged for this is: https://bugs.openjdk.java.net/browse/JDK-8266261 The defect indicated a JDK fix planned through the following sub-incidents : https://bugs.openjdk.java.net/browse/JDK-8266929 (for JDK 11 fixed in 11.0.12) https://bugs.openjdk.java.net/browse/JDK-8267766 (for JDK 8 fixed in 1.8.0_282) It is best to remain on a working JDK until JDK 8 update 302 or above is available. For JDK 11, this would be 11.0.12+
  14. Issue: When running a report in the TIBCO JasperReports® Server, the server becomes unresponsive and the report fails with the following error recorded in the jasperserver.log: 2021-05-22T10:51:47,463 ERROR AsyncJasperPrintAccessor,pool-7-thread-84:321 - Error during report execution net.sf.jasperreports.engine.JRRuntimeException: net.sf.jasperreports.engine.fill.JRExpressionEvalException: Error evaluating expression for source text: ((javax.sql.DataSource)((javax.naming.Context) (new javax.naming.InitialContext()).lookup("java:comp/env")).lookup("jdbc/prodassets")).getConnection()...Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object[/code]After restarting the Tomcat server, we are then able to run the report successfully. Solution:The error is an indication that the report was unable to get a connection from the db connection pool for connection to "prodassets" database. This could be associated to the max active connections being reached which may need to be increased. Steps: 1. Navigate to and edit the file:..jasperserver-proMETA-INFcontext.xml2. Increase the 'maxActive' value under Resource name "jdbc/prodassets". The default is:maxActive="100"maxActive is the maximum number of active connections that can be allocated from this pool at the same time. Note: Although there is a default value, there is no specific recommended value for this attribute as it depends on the requirement of each site. It should not be set too high since it can impact on system resources arising from too many active connections. A gradual increase and monitoring approach is suggested. 3. For the change to take effect, restart the Tomcat server[/code]There are other additional configurations that can be set to handle possible situations where connections are not being closed out automatically for it to return back into the connection pool. In terms of monitoring, you can log the abandoned connections to catalina.out by setting the attribute logAbandoned="true" in the JNDI connection. logAbandoned (boolean) Flag to log stack traces for application code which abandoned a Connection. Logging of abandoned Connections adds overhead for every Connection borrow because a stack trace has to be generated. The default value is false.[/code]Should there be any abandoned connections, the root cause should be investigated further through log file analysis of the stack traces. Setting the maxActive higher will only prolong the issue from occurring and restarting Tomcat server will release all these abandoned connections until the issue occurs again. The following attributes can be set so that abandoned connections are automatically removed once its time limit expires. These additional attributes are : removeAbandoned (boolean) Flag to remove abandoned connections if they exceed the removeAbandonedTimeout. If set to true a connection is considered abandoned and eligible for removal if it has been in use longer than the removeAbandonedTimeout Setting this to true can recover db connections from applications that fail to close a connection. See also logAbandoned. The default value is false.removeAbandonedTimeout (int) Timeout in seconds before an abandoned(in use) connection can be removed. The default value is 60 (60 seconds). The value should be set to the longest running query your applications might have.[/code] Please refer to the section "The Tomcat JDBC Connection Pool" of Apache Tomcat Reference for information on the above attributes. See Related Articles below for the direct link. Related Articles: https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html https://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html
  15. Issue:How can the message labels that appear on the JasperReports® Server Home Page be modified ? Below is a screenshot to illustrate an example of a highlighted message label as well as an example of a tooltip label that we would like to modify : Solution:The standard messages labels on the JasperReports® Server homepage are controlled by the HomeBundle.properties file. These messages can be modified to suit your requirement for any of the home page elements. Given the example provided, the following steps can be taken: 1. Navigate to and open the file :..jasperserver-proWEB-INFbundlesHomeBundle.properties2. Locate and edit the following :From: view.list=View list report.description=View and format interactive multi-page reports.To: view.list=This is my View list report.description=A customized message to view and format interactive multi-page reports.3. Restart the JR server for the changes to take effect [/code] The effect of the change after the restart will now look like this:
  16. Issue:We have configured Tomcat 9.0.1 to use the APR/native connector with HTTP/2 upgrade protocol. Upon testing our main and drill down reports, the main report shows loading and again the "You must apply input values before the report can be displayed." message appears. In the catalina log file, we observed that the following StackOverflowError error was captured : 01-Jun-2021 08:58:24.531 SEVERE [https-openssl-apr-443-exec-10] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading request, ignored java.lang.StackOverflowError at org.apache.coyote.http2.AbstractStream.isDescendant(AbstractStream.java:66) at org.apache.coyote.http2.AbstractStream.isDescendant(AbstractStream.java:70) ...[/code] The <TOMCAT>/conf/server.xml has the following connector configuration: <Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" maxHttpHeaderSize="65536" > <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" writeTimeout="60000" readTimeout="60000" keepAliveTimeout="60000"/> <SSLHostConfig> <Certificate certificateKeyFile="conf/localhost-rsa-key.pem" certificateFile="conf/localhost-rsa-cert.pem" certificateChainFile="conf/localhost-rsa-chain.pem" type="RSA" /> </SSLHostConfig> </Connector>[/code] Solution:The issue is related to a HTTP/2 bug that is fixed in Tomcat version 9.0.2. Refer to: Bug 61682 - StackOverflowError while executing HTTP/2 Server Push (https://bz.apache.org/bugzilla/show_bug.cgi?id=61682) All fixes for Tomcat 9.0.x are listed in the change log : https://tomcat.apache.org/tomcat-9.0-doc/changelog.html In order to overcome the specific error, upgrading to Tomcat 9.0.2 or above is required. Note: If running on Tomcat 8.5, then the error is fixed in Tomcat 8.5.24 and above. (https://tomcat.apache.org/tomcat-8.5-doc/changelog.html)
  17. Issue:We have a main report and a drilldown chart report. On the main report, we have an input control that contains more than 140 values. When a user selects a number of values from this input control greater than 110 and then attempt to perform a drilldown on the chart, the browser page reloads to display the following error: "This site can’t be reachedThe webpage at https://xxxxxxx might be temporarily down or it may have moved permanently to a new web address.ERR_HTTP2_PROTOCOL_ERROR"[/code]This only happens when the count of selected values goes beyond the threshold of 110, else the drill-down opens as expected. The drilldown request passing more than 110 parameter values as captured in a HAR file: Request URL: https://xxxxxxx/flow.html?_flowId=viewReportFlow&reportUnit=%2Fpublic%2F%2FReports%2Fdrilldown_report&Validity=2021-03-31&CalculationMethod=Percentage&Metric=2020&MyParameterValue=value1&MyParameterValue=value2&MyParameterValue=value3&MyParameterValue=value4&MyParameterValue=value5&MyParameterValue=value6&MyParameterValue=value7&MyParameterValue=value8&MyParameterValue=value9<..another 100 more of these &MyParameterValue...>&MyParameterValue=value111&LoggedInUserAttribute_UserCompany=xxxxx&_eventId_drillReport=&_flowExecutionKey=e5s2[/code]and the Response is: net::ERR_HTTP2_PROTOCOL_ERROR[/code]This issue has similar symptoms to the following article: "Hyperlinking to Another Report With Lots of Parameter Values Causes HTTP 400 Error" (See "Related Articles" section below for the link to the knowledge article) but the response error in this case is a ERR_HTTP2_PROTOCOL_ERROR and not a HTTP 400 error Solution:It is necessary to apply the maxHttpHeaderSize property as suggested in the mentioned article to avoid a HTTP 400 error. The default value of maxHttpHeaderSize is 8192 bytes which would be insufficient given that the HAR capture computed 15555 bytes for the header. The actual cause of the net::ERR_HTTP2_PROTOCOL_ERROR error is related to the HTTP/2 upgrade protocol that is configured in the Tomcat's server.xml. It may be necessary to set additional attributes such as the timeout properties below or it could be due to a bug in the HTTP/2 protocol depending on the exact Tomcat version used. (Refer to the "Related Articles" for Tomcat 9.0 change log for fixes) : <Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" maxHttpHeaderSize="65536" > <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" writeTimeout="60000" readTimeout="60000"/> <SSLHostConfig> <Certificate certificateKeyFile="conf/localhost-rsa-key.pem" certificateFile="conf/localhost-rsa-cert.pem" certificateChainFile="conf/localhost-rsa-chain.pem" type="RSA" /> </SSLHostConfig></Connector>[/code]Note: The writeTimeout, readTimeout attributes set increases the default limit of 5000 ms. For more information on HTTP/2 connector attributes, refer to "Related Articles" for a link to the Tomcat HTTP/2 reference. Note 2: Following any changes to the server.xml, the Tomcat server needs to be restarted. For any issues arising from testing the drilldown, the Tomcat server catalina log (for example <TOMCAT>/logs/catalina.2021-06-01.log) needs to be inspected at entries correlating to the time the drilldown exercise was performed. Workaround/Alternative :Implementation using HTTP/1.1 instead of HTTP/2. Modify <TOMCAT>/conf/server.xml to include maxHttpHeaderSize="65536" and remove <UpgradeProtocol>: <Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" maxHttpHeaderSize="65536"> <SSLHostConfig> <Certificate certificateKeyFile="conf/localhost-rsa-key.pem" certificateFile="conf/localhost-rsa-cert.pem" certificateChainFile="conf/localhost-rsa-chain.pem" type="RSA" /> </SSLHostConfig></Connector>[/code]Note 3: Although this approach may resolve the problem but since it is configured to use HTTP/1.1 instead of HTTP/2, you would not be able to take advantage of the benefits of using HTTP/2. Related Articles:https://community.jaspersoft.com/wiki/hyperlinking-another-report-lots-parameter-values-causes-http-400-errorhttps://tomcat.apache.org/tomcat-9.0-doc/config/http.htmlhttps://tomcat.apache.org/tomcat-9.0-doc/config/http2.htmlhttps://tomcat.apache.org/tomcat-9.0-doc/changelog.htmlhttps://community.jaspersoft.com/wiki/tomcat-server-connector-implementing-http2-upgrade-protocol-generates-stackoverflowerror-error
  18. Issue:TIBCO JasperReports® Server allows report jobs to be scheduled to an FTP Server as an output destination. How to best debug an FTP connection issues upon encountering any errors with the scheduled jobs? One such use case is when users are able to configure scheduled report jobs with multiple FTP connections connecting to different FTP Servers. The standard set of logging components does not log the ip address to be able to track which FTP Server the connection was made. Are there any additional logging that can be set to generate further debugging information ? Solution:In the "Output Options" page, there is a "Test Connection" button that can test for connection failures. Below are the typical errors that can be generated in the ../WEB-INF/logs/jasperserver.log upon clicking on "Test Connection" : 2020-06-12T11:19:20,472 ERROR SecureExceptionHandlerImpl,http-nio-8080-exec-4:116 - Auth fail2020-06-12T11:20:28,072 ERROR SecureExceptionHandlerImpl,http-nio-8080-exec-3:116 - No such file2020-06-12T11:24:07,180 ERROR SecureExceptionHandlerImpl,http-nio-8080-exec-2:116 - java.net.ConnectException: Connection refused: connect2020-06-12T11:28:14,744 ERROR SecureExceptionHandlerImpl,http-nio-8080-exec-4:116 - java.net.UnknownHostException: 172.17.18.6767[/code]The conditions for when the above errors would be generated are: When directory is invalid, the "No such file" error When username or password is invalid, the "Auth fail" errorWhen port is invalid, the "Connection refused: connect" error When server address is invalid, the "java.net.UnknownHostException"For further debugging to be logged, the following logger component can be manually added to the "Server Settings" -> "Log Settings" to log extra FTP specific debug information (such as IP address) to the jasperserver.log: com.jaspersoft.jasperserver.api.engine.common.util.impl.FTPUtil An example is when the connection is successful it logs the IP and further DEBUG messages following the successful connection: 2021-05-18T19:27:28,273 DEBUG FTPUtil,JasperServerScheduler_Worker-2:236 - FTP: connected to 172.17.18.204 LOGIN OK.2021-05-18T19:27:28,274 DEBUG FTPUtil,JasperServerScheduler_Worker-2:246 - Connected to 172.17.18.204 REPLY OK.[/code]For multiple FTP Servers, this extra level of information would be handy to know which FTP Server a report job was connected to. The debug information is based on specific conditions written inside the class, com.jaspersoft.jasperserver.api.engine.common.util.impl.FTPUtil (packaged inside ..WEB-INFlibjasperserver-api-engine-impl-7.9.0.jar). An extract of the code is pasted below: public class FTPServiceClientImplimplements FTPService.FTPServiceClient{private FTPClient ftpClient = null;public FTPServiceClientImpl(String host, int port, String userName, String password)throws Exception{this.ftpClient = new FTPClient();this.ftpClient.connect(host, port);if (!this.ftpClient.login(userName, password)){this.ftpClient.logout();throw new JSException("FTP: Fail to login: may due to invalid username/ password.");}if (FTPUtil.log.isDebugEnabled()) {FTPUtil.log.debug("FTP: connected to " + host + " LOGIN OK.");}int reply = this.ftpClient.getReplyCode();if (!FTPReply.isPositiveCompletion(reply)){this.ftpClient.disconnect();throw new JSException("FTP: unable to connect to " + host);}if (FTPUtil.log.isDebugEnabled()) {FTPUtil.log.debug("Connected to " + host + " REPLY OK.");}this.ftpClient.enterLocalPassiveMode();[/code]
  19. Issue:The Scheduled Jobs page has checkboxes against each job to allow the user to enable/disable the individual job. However, in a production environment where there can exist hundreds of active report jobs scheduled, it is a cumbersome task for any system administrator to manually disable all jobs. The premise for such a requirement could be to disable all active jobs prior to undertaking an upgrade so that the jobs will not be potentially triggered during the upgrade. There is no batch mode feature in the TIBCO JasperReports Server user interface to batch disable all active jobs. What alternatives are there to accomplish this ? Solution:The state of the scheduled job is stored in the repository table, qrtz_triggers and the column name is the trigger_state. When a job is disabled in the UI by unchecking the checkbox, the 'trigger_state' column reflects the state as "PAUSED". Although it is technically possible to update the table column using backend SQL update execution, such approach is unsupported and not a recommendation by Product Support due to its invasiveness, and as with all backend sql approaches in updating system tables, updating the table incorrectly can lead to data corruption. Despite the TIBCO JasperReports® Server UI not having a batch update mode, a different approach can be done using Web Services. The recommended approach is to use the REST API to 'pause' and 'resume' scheduled jobs. In the TIBCO JasperReports® Server REST API Reference, there is a POST method api which allows the system administrator to pause one or many or all scheduled jobs and subsequently to resume these jobs. For more detailed information, please refer to TIBCO JasperReports® Server REST API Reference sections "Pausing Jobs" and "Resuming Jobs". The direct links to the v7.1 documentation are: https://community.jaspersoft.com/documentation/tibco-jasperreports-server-rest-api-reference/v710/jobs-service#Pausing_Jobs https://community.jaspersoft.com/documentation/tibco-jasperreports-server-rest-api-reference/v710/jobs-service#Resuming_Jobs
  20. Issue:In Job Conductor page of Talend Administration Center, a new cron-based trigger was configured for tasks to run every 15 minutes as per below screen: The trigger is associated to the task but instead of scheduling every 15 minutes, the task is scheduled at every hour as illustrated by the "Time left before next triggering" and "Next triggering on" columns. Solution:The issue was caused by a misunderstanding of the Cron UI configuration usage. As per the provided example above, the configuration does not mean the task will be executed every 15 minutes but rather 15 minutes past every hour. There is a "Open Cron Help" button that once clicked will display a dialog detailing more information on the usage of Cron UI settings. Refer to the list of cron settings based on sample use-cases as this can assist in the setting the right values. For configuring a cron-based trigger to run a task every 15 minutes, the correct value set in the "Minutes" textbox should be 0/15.
  21. Below are the sample JSON constructs for adding a resource file (such as "Logo.png") and an Input control ("Stmt_Date") to a newly created Report Unit ("TESTREPORT"). Request: POST http://<server>:8080/jasperserver-pro/rest_v2/resources/Reports Authorization username: jasperadmin|Test (Note: 'Test' is an Organization) password: jasperadmin Headers: Accept: application/json Content-Type: application/repository.reportUnit+json 1> After adding the resource file to a repository folder eg. /publicREST BODY: { "label": "TESTREPORT", "dataSource": { "dataSourceReference": { "uri": "/public/DataSources/foodmart_jdbc" } },"query": null,"inputControlRenderingView": "","reportRenderingView": "","alwaysPromptControls": true,"controlsLayout": "popupScreen", "inputControls": [ { "inputControl": { "label": "Stmt_Date", "mandatory": false, "readOnly": false, "visible": true, "type": 2, "dataType": { "dataType": { "label": "myDatatype", "type": "date", "strictMax": false, "strictMin": false } } } } ], "resources": { "resource": [ { "name": "Logo", "file": { "fileReference": { "uri": "/public/Logo.png" } } } ] }, "jrxml": { "jrxmlFile": { "type": "jrxml", "label": "mainReport", "content": "<base64 encoded content>" } }}[/code] 2> When resource file is added as a base64 encoded content (not residing in the repository)REST BODY: { "label": "TESTREPORT", "dataSource": { "dataSourceReference": { "uri": "/public/DataSources/foodmart_jdbc" } },"query": null,"inputControlRenderingView": "","reportRenderingView": "","alwaysPromptControls": true,"controlsLayout": "popupScreen", "inputControls": [ { "inputControl": { "label": "Stmt_Date", "mandatory": false, "readOnly": false, "visible": true, "type": 2, "dataType": { "dataType": { "label": "myDatatype", "type": "date", "strictMax": false, "strictMin": false } } } } ], "resources": { "resource": [ { "name": "Logo", "file": { "fileResource": { "label": "Logo.png", "type": "img", "content": "<base64 encoded content of logo.png>" } } } ] }, "jrxml": { "jrxmlFile": { "type": "jrxml", "label": "mainReport", "content": "<base64 encoded content of jrxml file>" } }}[/code]Screenshot of the Report Unit created:
  22. Issue:In a report with a table component, there are JIVE interactivity options which allows for filtering, sorting, formatting as well as a marker for column width resize by dragging the column side ways. How do we hide the icon (which resembles an "upside down triangle") that marks the column width ? Solution: The icon for column width resizing is rendered by the dragMarker.png located internally in the jasperreports-6.11.0.jar at location: netsfjasperreportscomponentsheadertoolbarresourcesimagesjivedragMarker.png In order to hide this column marker, it can be overriden through javascript inside the overrides_custom.css file of a custom theme. The idea is to reduce the icon pixel width and height to a small enough value that renders it non-visible, such as 1px. Original: #jive_marker_icon { background: url(/jasperserver-pro/reportresource/reportresource?resource=net/sf/jasperreports/components/headertoolbar/resources/images/jive/dragMarker.png); width: 10px; height: 16px; position: relative; top: -16px; left: -10px;}[/code]Modified: body #jive_marker_icon { background: url(/jasperserver-pro/reportresource/reportresource?resource=net/sf/jasperreports/components/headertoolbar/resources/images/jive/dragMarker.png); width: 1px; height: 1px; position: relative; top: -16px; left: -10px;}[/code]Note: With the tracing through FireFox dev console (F12) Inspector tab and by navigating the JIVE interactive menu, you would be able to locate the relevant javascript under the <div> jive_components. Steps: 1. Create a custom theme folder under Public -> Themes 2. Upload to the custom theme folder using File -> CSS, the overrides_custom.css containing the modified javascript 3. Set the custom theme as the active theme. Attached are screenshots illustrating a Report with the Firefox Inspector tab being effected by overrides_custom.css file.
  23. Review the Ultimate guide on how to design a cluster. This part covers shared repository database and includes sample configurations for session replication. https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v780/designing-cluster
  24. Looks like a permissions problem with the user starting tomcat. Access to the temp directory is needed. You can delete subdirectories: main, buffer, adhocCache and try again.
  25. Issue:After making changes to the applicationContext*.xml files, the TIBCO JasperReports® Server failed to successfully start. The folllowing exceptions were captured in the jasperserver log: [toc]2020-09-26 08:18:04,856 ERROR ContextLoader,localhost-startStop-1:350 - Context initialization failedorg.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'org.springframework.transaction.config.internalTransactionalEventListenerFactory' defined in null: Cannot register bean definition [Root bean: class [org.springframework.transaction.event.TransactionalEventListenerFactory]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] for bean 'org.springframework.transaction.config.internalTransactionalEventListenerFactory': There is already [Root bean: class [org.springframework.transaction.event.TransactionalEventListenerFactory]; scope=; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false;factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null] bound. at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:812)[/code]We are unable to determine what changes were made that led to this problem. How do we trace what files were modified in order for the server to restart successfully again ? Solution: Error messages showing "There is already ...." implies that there is a conflict in the bean 'TransactionalEventListenerFactory' but the error can occur with any conflicting beans. This can happen when there is another copy of the same applicationContext*.xml file (such as one that was cloned with a suffix of 'backup') located in the same /webapps/jasperserver-pro/WEB-INF/ directory causing the conflict since it was also being loaded upon the server restart. The TIBCO JasperReports® Server needs to be brought down fully and remove the conflicting file before restarting the server. Another way of identifying conflicts is through comparing all the *.xml files under the ../webapps/jasperserver-pro/WEB-INF/ with that of the last known successful restart of the TIBCO JasperReports® Server....such as that from a file server backup copy or another instance of the same version.
×
×
  • Create New...