Issue:

When exporting an Ad Hoc View or Report to Excel, the Excel output displays the timezone in the system timezone and not in the users logged in timezone.

Solution:

For export to Excel, you would need to set this property to true:

net.sf.jasperreports.export.xls.use.timezone

This property determines whether date values are to be translated to the timezone that was used to fill the report. 

The property only has effect when net.sf.jasperreports.export.xls.detect.cell.type is also set to true.

By default, date values are exported to Excel using the default timezone of the system.

More information can be found on this page:

http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.export.xls.use.timezone

There are 2 issues encountered whilst trying to preview the sample report, JsonCustomersReport.jrxml, under JasperReportsSamplesjsondatasource:

1. Previewing the JsonCustomersReport.jrxml produces a report with null data.

2. Previewing the JsonCustomersReport.jrxml generates error "Unable to get value for JSON field "OrderDate" of class java.util.Date".

Solution:

1. The data adapter is showing up as "One Empty Record" for the Json sample report to show null. It is necessary to create a JSON data adapter (eg "JSONData") with a File/URL pointing to "..jsondatasourcedatanorthwind.json" as the data source. This data source can then be used for the sample json reports. This property can be referenced in the Advanced tab -> Properties property or in the Source tab:

   <property name="net.sf.jasperreports.json.source" value="data/northwind.json"/>
   <property name="com.jaspersoft.studio.data.defaultdataadapter" value="JSONData"/>
   

1. The OrderDate class type is set to java.util.Date by default for the subreport JsonOrdersReport.jrxml. In order to resolve the error:

   1. Open JsonOrdersReport.jrxml and in the Design tab.

   2. Expand Fields and click on field OrderDate. 

   3. Modify the OrderDate class type from java.util.Date to java.sql.Date.

   4. Save and re-compile the report to regenerate the .jasper file.
      
      NOTE : The article describes a specific use case and presents a generic solution that may be applicable for troubleshooting or resolving similar issues.

User is getting a response error "401 unauthorized" for a REST request made from their application using JasperRestClient.getDashboards() method.

GET https://usersclient.com/jasperserver-pro/rest_v2/resources?folderUri=/public/Dashboards 

returned a response status of 401 Unauthorized 

Resolution

It is suggested to check proper access permission of resource folder and temp folder for TIBCO JasperReports^® Server user used to initiate the request from their application. Alternately, it is advised to use superuser to initiate the request from their application which resolved the error.

Note

ROLE_SUPERUSER alone will not secure a resource access permission. This role must be used in conjunction with ROLE_ADMINISTRATOR to work correctly. Please review this web posting in customer wiki site for further detail: 

https://community.jaspersoft.com/wiki/why-user-rolesuperuser-assignment-does-not-seem-have-superuser-privileges

TTC-20190429

org.apache.catalina.LifecycleException: Failed to start component [org.apache.catalina.webresources.StandardRoot@1c994238]

..........

java.util.zip.ZipException: error in opening zip file

Diagnose

The installation log file for this TIBCO JasperReports Server instance confirmed it was successfully installed; therefore, the only possible explanation of this zip file opening error is that either a change was unintentionally made to the TIBCO JasperReports Server instance (unbeknownst to the user), or some events occurred that corrupted a jar file in the deployment.

Resolution

A close review to this TIBCO JasperReports Server deployment, it appears someone had put some custom jar files in this deployment which contain an incorrect structure that Tomcat is not able to expand its class methods from the jar zips therefore causing the deployment error at server start-up time.

After removing those suspected problematic jars from TIBCO JasperReports Server installation (jasperserver-proWEB-INFlib directory), TIBCO JasperReports Server started successfully. 

It is suggested that should users do need those class methods in those jars for product customization, they need to make sure the jars are created correctly and compatible with JVM version 1.8 bundled with TIBCO JasperReports Server 7.1.0.

TTC-20190422-1739030

Note: This is a specific use case related to the custom jar placed in the classpath of Jasperserver v7.1

You might be deploying JasperServer in OpenShift using Docker files. When running reports from the instance using visualize.js you are consistently getting a CORS error on OPTIONS settings.html request with 403 Forbidden response.  
Specific error is, No 'Access-Control-Allow-Origin' header is present on the requested resource.

- Your version of jasperserver is v7.9.0.
- Domain whitelist set to *
- The log file seems to indicate that the request did not go through the CORS filter
- and none of the documented known CORS related settings seem to matter.

Possible Solution:

Check and see if you have deleted anonymous user from root.  If so, add it back and see if it works. If it works, the problem is related to a known issue logged under JS-62587.
Check with your support engineer to see what the latest update is for this issue.

Problem:

There is a JasperReports Server that is deployed behind an IIS proxy. When users are running ad hoc reports with a large number of filters/input controls the filtering does not get applied. The REST request for the filters returns a 400 error:

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 28 Aug 2015 16:45:30 GMT
Connection: close
Content-Length: 324

Solution:

This solution is only relevant if you have JasperReports Server deployed behind IIS. IIS is used quite commonly as a proxy server that sits in front of the application server in Windows shops. Default settings of the proxy server permit you from sending requests with large URL segment which is what happens in this case. They get defaulted to 400 response and fail. The default limit for the URL segment is 260 characters, the setting is found in the http.sys settings on Windows Servers.

The defaults, which are unspecified on a stock Windows Server 2008 install, are documented on this KB,

https://support.microsoft.com/en-us/kb/820129

The relevant setting in this case is named "UrlSegmentMaxLength", a DWORD value with a default of 260, can be configured between 0 - 32,766 chars. In the above example, the largest segment generated in the ajax request was 760 chars.

Increasing the setting to 8092 in the registry, and rebooting the server resolves the issue for the foreseeable future.

In a report, we are trying to use the column filter on a table column field to filter on values matching the condition but it does not return the expected rows. 

For example:

In the report there is a table with a field containing value 1.629214.

We set the  'Column filters' on this column to:

Condition: "Show only rows where" Equals 1.629214 

Result: There are no rows returned

We noticed that when we select the 'Column filters' again, the actual value was automatically truncated to 1.629 instead of keeping the entered value of 1.629214.

How do we resolve this so that we get the results returned for the exact filter value entered ?

Solution:

There is a configurable pattern in:

<jasperserver-webapp>/WEB-INF/bundles/jasperreports_messages[_lang[_country]].properties

under the key:

net.sf.jasperreports.components.number.pattern

that defaults to:

###,###.###

This can be adjusted to contain more digits after the decimal place :

###,###.######

The pattern is used to adjust both numbers on server and the ones coming from the UI when comparing them for filtering purposes.

ref: 01844211 

Issue:

As per the command:

pg_dump --username=postgres  jasperserver  >  js-db-dump.sql

we received an error message:

pg_dump: [archiver (db)] connection to database "jasperserver" failed: could not connect to server: No such file or directory

Is the server running locally and accepting

connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

To get rid of this error, we tried the following command for backup:

pg_dump jasperserver -U jasperdb -h localhost > js-db-dump-13FEB2020.sql

but received:

connection to database "jasperserver" failed: could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

How to overcome these issues to successfully generate the dump file ?

Solution:

The error represents a connection problem to the postgres database. 

So it is essential to firstly know whether the postgres is running and on what port number (default port is 5432). 

Once you know this information, you can use this to force the connection with extra parameters passed with the pg_dump command :

-h host 

-p port

-U username

-W

You can refer to the following page for reference:

https://www.postgresql.org/docs/9.3/app-pgdump.html

If it is still an issue and the error that you are getting remains exactly the same then probably there is an incorrect path to socket. 

Backup tried to connect to /var/run/postgresql/.s.PGSQL.5432 but it does not exist. Hence you can check this article:

https://stackoverflow.com/questions/31645550/why-psql-cant-connect-to-server

to check for the location of the socket file and verify the configuration files, pg_hba.conf and postgresql.conf are correctly set.

There are mentions to check for unix_socket_directories parameter setting and set it to /tmp. 

It is recommended to check that this parameter is in place as well:

listen_addresses = '*'

Issue:

In JasperReports^® Server 6.3, when using Internet Explorer 11, crosstab and table header toolbar buttons are not visible. The user can only see an outlined box. Due to this issue, users are unable to click on the Formatting, Filter, and Sort icons to display results. 

This issue does not occur with other browser types such as Chrome or Microsoft Edge.

Solution:

The issue can arise in situations where there is infrastructure security hardening implemented on the network. As part of the security hardening, the "X-Content-Type-Options: nosniff" was included in the HTTP configuration which blocks the image from displaying without a mime-type set.

The issue has been fixed in a later release with modifications to the jasperreports_extension.properties file. 

The workaround is to modify the jasperreports_extension.properties file located under WEB-INFclasses (or in a location that's part of your application's classpath) and add the following lines:

net.sf.jasperreports.extension.registry.factory.content.type.mapping=net.sf.jasperreports.web.util.ContentTypeMappingExtensionsRegistryFactory

net.sf.jasperreports.extension.content.type.mapping.png=image/png

net.sf.jasperreports.extension.content.type.mapping.gif=image/gif

Related article:

http://community.jaspersoft.com/jasperreports-library/issues/9511

Issue:

Using REST_v2 API to try and set the theme of a sub-organization, 'East_Chain', the response returned is a 404 status code. 

Basic Auth

username: superuser

password: superuser

Request

PUT: http://<server>:8080/jasperserver-pro/rest_v2/jasperserver-pro/rest_v2/organizations/Top_Chain/East_Chain

or 

PUT: http://<server>:8080/jasperserver-pro/rest_v2/jasperserver-pro/rest_v2/organizations/Top_Chain/organizations/East_Chain

Body

{
"theme":"pods_summer"
} 

How to successfully set the theme for a sub-organization ?

Solution:

The REST API service only has the structure to set the theme to an organization and not to a sub-organization.

Setting this:

/jasperserver-pro/rest_v2/organizations/Top_Chain/East_Chain

will return 404 because the REST API expects this format:

/jasperserver-pro/rest_v2/organizations/<organization>

and hence <organization> then becomes "Top_Chain/East_Chain" which doesn't exist.

In order to set the theme to a sub-organization, "East_Chain":

1> Set the REST authentication to the administrator of the parent organization. For example:

Basic Auth

username: jasperadmin|Top_Chain

password: jasperadmin

2> Issue a REST call like this:

PUT: http://<server>:8080/jasperserver-pro/rest_v2/organizations/East_Chain

For more information on setting themes to an organization, refer to "TIBCO JasperReports® Server REST API Reference" section "21.5 Setting the Theme of an Organization"

ref 01844815 

You have a report with a text field where you want to use styled text markup. For example:

"<style><b>Some text: </b></style>" + $F{SomeField}

While this works fine for most fields, some fields do not get the bold style applied.

Solution:

Styled text is essentially an XML and follows the same rules and restrictions as XML. $F{SomeField} which is appended to styled text might contain symbols which are not allowed in XML without escaping them like ampersand. These symbols need to be escaped before appending.


NOTE: "<style><b>Company Name: </b></style>" + net.sf.jasperreports.engine.util.JRStringUtil.xmlEncode($P{TestData})

After using the above and the bold styling will now render perfectly without being broken by special characters!

SELECT customer_credit."CUSTOMER_ID", customer_credit."CUSTOMER_NAME", customer_credit."CREDIT",
customer_sale."YEAR" || '-' || lpad(customer_sale."MONTH"::text,2,'0') as "SALE_MONTH",customer_sale."SALE_AMOUNT" 
FROM
public."customer_credit" 
RIGHT JOIN public."customer_sale" ON
customer_credit."CUSTOMER_ID" = customer_sale."CUSTOMER_ID"
ORDER BY customer_credit."CUSTOMER_ID",customer_credit."CUSTOMER_NAME", customer_sale."YEAR", customer_sale."MONTH"

The result of this join produces a dataset where the sum of the CREDIT field is 600. This is the main dataset query behind the Crosstab report. 

After creating a Crosstab, the aggregation for CREDIT is incorrect as illustrated below:

This is because the TOTAL CREDIT (shown as 600) is derived from the SUM of the CREDIT field based on the dataset query. 

What needs to be done to accurately calculate the TOTAL CREDIT so that the value reflects 150 instead of 600 ?

Solution:

The only solution is to create a report group on CUSTOMER, and feed to the crosstab measure $F{CREDIT} for the first record in the group and 0 for all other records. Note that this takes advantage that the query orders the records by CUSTOMER_ID (and CUSTOMER_NAME).

Steps:

1. In the crosstab outline tab, create group CUSTOMER with Expression $F{CUSTOMER_ID}:

   

   

2. For TOTAL_CREDIT Measure, set the Expression to :"$V{CUSTOMER_COUNT} == 1 ? $F{CREDIT} : 0" and ensure Calculation is SUM.

   

Note that the CUSTOMER_COUNT variable will be automatically created after creating the CUSTOMER group.

This is the end result:

See attached JRXML and other scripts to sample this report. Attached are:

1. JRXML file containing simple crosstab

2. postgrescreatesql.txt containing sql statement to to create and populate the two tables

3. report_query_postgres.sql which is the query behind the report 

postgrescreatesql.txt

report_query_postgres.sql

crosstab_row_group_total_test_modified.jrxml

During JasperServer installation, upgrade, or import/export (iePro) tasks using Buildomatic, the process fails to connect to the database. The error log specifically indicates a failure to parse the JDBC connection string, highlighting escaped ampersand characters (&).

The error stack trace looks like this:

[java] ERROR SqlExceptionHelper:150 - Cannot create PoolableConnectionFactory (Cannot load connection class because of underlying exception: com.mysql.cj.exceptions.WrongArgumentException: Malformed database URL, failed to parse the connection string near ';characterEncoding=UTF-8&autoReconnectForPools=true&tinyInt1isBit=false&sslMode=REQUIRED&allowPublicKeyRetrieval=true'.)

Cause

This error is caused by a syntax conflict between XML escaping rules and Java .properties file parsing, and it specifically surfaces when the system is actively using the official Oracle MySQL JDBC Driver (mysql-connector-j).

Buildomatic utilizes various configuration files. While standard XML files require ampersands to be escaped as & to be considered valid, Java .properties files (and the underlying Spring Framework that reads them) expect standard, unescaped & symbols to separate URL parameters.

If a user or administrator updates the JDBC URL templates in the db.template.properties file and accidentally uses the XML-escaped & instead of a standard &, the native Oracle MySQL JDBC driver attempts to read amp; as a literal part of the parameter name. This breaks the expected URL syntax, causing the driver to throw a Malformed database URL exception. (Note: The MariaDB drop-in driver parses these differently and may not throw this specific exception).

Resolution

To fix this, you must remove the XML-escaped ampersands from the JDBC URL templates and replace them with standard ampersands.

Step 1: Locate the Database Template File Navigate to your Buildomatic configuration source folder and open the database template properties file for your specific database (e.g., MySQL): <js-install>/buildomatic/conf_source/db/mysql/db.template.properties

Step 2: Correct the Connection Strings Look for the JDBC URL properties (such as admin.jdbcUrl, js.jdbcUrl, sugarcrm.jdbcUrl, etc.). Find any instances of & and replace them with &.

Incorrect (Malformed):

js.jdbcUrl=jdbc:mysql://${dbHost}:${dbPort}/${js.dbName}?useUnicode=true&characterEncoding=UTF-8&sslMode=REQUIRED

Correct:

js.jdbcUrl=jdbc:mysql://${dbHost}:${dbPort}/${js.dbName}?useUnicode=true&characterEncoding=UTF-8&sslMode=REQUIRED

Step 3: Check default_master.properties (Optional) If you have explicitly overridden the js.jdbcUrl or other connection strings directly inside your <js-install>/buildomatic/default_master.properties file, ensure you make the exact same correction there.

Step 4: Re-run Buildomatic Once the files are saved, re-run your Buildomatic command. The Spring framework will correctly parse the URL parameters and establish the connection.

When installing or configuring JasperServer against a modern MySQL 8.x (or 8.4) database that mandates secure transport (--require_secure_transport=ON), connections fail during the Buildomatic iePro (import/export) phase or application runtime.

Users often encounter one of two errors:

1. Access Denied / Insecure Transport: Connections using insecure transport are prohibited while --require_secure_transport=ON.

2. PKIX Error: Setting legacy JDBC properties to force SSL results in PKIX path building failed before authentication completes.

Cause

Starting in MySQL Connector/J 8.0.13, Oracle overhauled security parameters. They deprecated legacy individual flags (useSSL, requireSSL, verifyServerCertificate) and consolidated them into a single parameter: sslMode.

When configuring JasperServer's Spring data sources (like ConfigurableDataSource or DBCP pools):

• Mixing legacy properties (useSSL=true) with modern properties confuses the driver, often causing it to default to strict Java TrustManager validation, triggering a PKIX error.

• Passing empty or deprecated properties can cause the driver to silently fall back to plain-text, triggering MySQL's strict require_secure_transport rejection.

Resolution

To properly configure a modern MySQL 8.x database connection in JasperServer that enforces encryption but cleanly bypasses the Java keystore certificate validation, you should determine which underlying JDBC driver your application is actually using and apply the corresponding properties.

Step 1: Locate your data source configuration Identify where your connection is being established. This is typically found in:

• buildomatic/conf_source/db/mysql/db.template.properties (for installations)

• buildomatic/conf_source/iePro/applicationContext-export-config.xml (for export/import operations)

• META-INF/context.xml (for Tomcat JNDI connections post-installation)

Step 2: Apply the Appropriate Driver Parameters

Pathway 1: Official Oracle MySQL Driver (Standard)

If your system is correctly utilizing the official MySQL driver (mysql-connector-j), you must exclusively use the modern parameters and eliminate all legacy flags.

Remove any instances of useSSL=true, requireSSL=true, or verifyServerCertificate=false. Instead, append the following directly to your JDBC URL or within your <map> of extra properties:

sslMode=REQUIRED&allowPublicKeyRetrieval=true

(Note: If configuring within an XML file, ensure the ampersand is escaped as &)

How it works:

• sslMode=REQUIRED instructs the driver to establish an encrypted SSL tunnel (satisfying --require_secure_transport=ON), while simultaneously instructing the driver to not strictly verify the certificate against the Java cacerts keystore (preventing the PKIX error).

• allowPublicKeyRetrieval=true is necessary for MySQL 8's default caching_sha2_password authentication plugin to exchange credentials securely over the newly established tunnel.

Pathway 2: MariaDB Driver Fallback

If you apply the properties from Pathway 1 and find that they are completely ignored (e.g., the server continues to throw "insecure transport" errors), your JasperServer instance may be experiencing "Driver Stealing." This means the application is silently utilizing the bundled MariaDB JDBC driver instead of the Oracle MySQL driver.

Because the MariaDB driver ignores MySQL's sslMode parameter, you must use its accepted legacy properties along with a specific MariaDB property to bypass hostname verification.

Instead of sslMode, append the following properties:

useSSL=true&requireSSL=true&disableSslHostnameVerification=true

Next Steps: If Pathway 2 resolves your connection issue, your system is actively using the MariaDB driver. For a detailed explanation of why this driver hijacking happens and instructions on how to permanently remove the MariaDB driver to force the system to use the official Oracle MySQL driver, please read the following article: Database Connection Error: SSL hostname verification failed (disableSslHostnameVerification)

When running Buildomatic or attempting to connect JasperServer to a database over an SSL-encrypted connection, the connection pool fails to initialize, resulting in a fatal error during the build or deployment phase.

The error log specifically mentions a SunCertPathBuilderException:

[java] ERROR SqlExceptionHelper:142 - Cannot create PoolableConnectionFactory (Could not connect to address=(host=your.db.host)(port=3306)(type=master) : Could not connect to your.db.host:3306 : (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)

Cause

This error occurs during Step 1 of the database connection sequence (The SSL Handshake).

Java successfully reaches the database server and initiates an encrypted tunnel. However, the database server presents an SSL certificate that the Java Virtual Machine (JVM) does not recognize or trust (often an auto-generated or self-signed certificate, such as the default MySQL 8 server certificate).

Because the JVM's TrustManager cannot verify the certificate's root of trust against its internal cacerts keystore, it immediately terminates the connection for security reasons, resulting in the PKIX path building failed error.

Resolution

While connection string parameters (like verifyServerCertificate=false or sslMode=REQUIRED) can sometimes bypass this check, the most robust and guaranteed solution is to import the database's SSL certificate directly into the JVM's keystore.

Step 1: Extract the Certificate from the Database From a terminal with network access to the database, use OpenSSL to extract the public certificate. Run the following command (replace the host and port with your DB details):

echo -n | openssl s_client -connect your.db.host:3306 -starttls mysql | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > db_cert.pem

Step 2: Import the Certificate into Java Locate the specific JAVA_HOME path that JasperServer/Buildomatic is utilizing. Use the keytool utility to import the db_cert.pem file into the cacerts keystore.

sudo keytool -import -alias jasper-db-cert -file db_cert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts

Note: The default keystore password for Java is changeit. When prompted "Trust this certificate?", type yes.

Step 3: Rerun the Process Once the certificate is imported, Java will natively trust the database's secure transport. Rerun your Buildomatic or JasperServer startup script. The PKIX error will be resolved, allowing the connection to proceed to the authentication phase.

During the installation, upgrade, or import/export (iePro) phase using Buildomatic with a MySQL database, the build fails with connection errors that reference MariaDB-specific properties.

Even though default_master.properties is explicitly configured to use the official Oracle MySQL driver (com.mysql.cj.jdbc.Driver / mysql-connector-j), the log outputs errors such as:

[java] ERROR SqlExceptionHelper:142 - Cannot create PoolableConnectionFactory (Could not connect to address=(host=your.db.host)(port=3306)(type=master) : SSL hostname verification failed : DNS host "your.db.host" doesn't correspond to certificate CN "mysql_server_8.4.x_auto_generated_server_certificate"
[java] This verification can be disabled using the option "disableSslHostnameVerification" but won't prevent man-in-the-middle attacks anymore)

Cause

This is caused by a Java Classloader phenomenon known as "Driver Stealing," which often surfaces when administrators attempt to troubleshoot SSL connections by adding explicit JDBC properties to the data source configuration.

Typically, this becomes apparent when users notice that modern MySQL properties like sslMode=REQUIRED are completely ignored, but adding legacy properties like useSSL=true directly to the dataSource bean's extraProperties map within the buildomatic/conf_source/iePro/applicationContext-export-config.xml file actually triggers an SSL connection attempt. This selective parameter handling is a strong indicator that the MariaDB driver is actively handling the connection instead of the Oracle MySQL driver.

The property disableSslHostnameVerification mentioned in the error does not actually exist in the official Oracle MySQL Connector/J driver; it is an exclusive property of the MariaDB Connector/J.

Because the MariaDB driver is engineered to be a drop-in replacement for MySQL, it is programmed to accept the jdbc:mysql:// URL prefix. If the mariadb-java-client.jar is present in the local iePro/lib directory, the Java classloader loads it into memory before it reaches the global shared libraries.

When Spring asks the DriverManager to connect to jdbc:mysql://, the MariaDB driver answers first, intercepts the connection string, and executes the connection using MariaDB logic. This causes standard MySQL 8 parameters to be ignored and throws MariaDB-specific SSL errors when encountering self-signed or auto-generated database certificates.

Resolution

There are two ways to resolve this issue: you can either embrace the MariaDB driver and provide the property it is asking for, or you can remove the MariaDB driver to force the system to use the official MySQL driver.

Option 1: Use the MariaDB Driver (Quick Fix)

If you do not mind using the MariaDB driver (which is officially supported by Jaspersoft as a MySQL drop-in), you can simply provide the property the error message is asking for to bypass the hostname mismatch.

1. Open the file <js-install>/buildomatic/conf_source/iePro/applicationContext-export-config.xml.

2. Locate the dataSource bean and its extraProperties map.

3. Add the disableSslHostnameVerification entry to the map alongside your SSL properties:

   <property name="extraProperties">
     <map>
       <entry key="useSSL" value="true" />
       <entry key="requireSSL" value="true" />
       <entry key="disableSslHostnameVerification" value="true" />
     </map>
   </property>
   
   

4. Rerun your Buildomatic command.

Option 2: Force the Oracle MySQL Driver (Root Cause Fix)

To resolve the underlying hijacking issue and force Buildomatic to use the correct Oracle MySQL driver specified in your default_master.properties, you must remove the conflicting MariaDB jar from the local application library folder.

1. Navigate to your JasperServer installation or Buildomatic root directory.

2. Locate the mariadb-java-client jar file inside the iePro library. Typical path: <js-install>/buildomatic/conf_source/iePro/lib/mariadb-java-client-x.x.x.jar

3. Delete or move this .jar file out of the lib directory.

4. Rerun your Buildomatic command (e.g., ./js-install.sh or ./js-ant import).

By removing the MariaDB jar from the localized iePro/lib folder, the Java classloader will fall back to the global conf_source/db/mysql/jdbc directory, successfully load the intended mysql-connector-j driver, and process standard MySQL configuration parameters (like sslMode=REQUIRED) correctly.

You have exported the organization and now try to import it to another server. When importing you get an error: "Import failed. Import of the root to an organization is not allowed"

Solution:

This issue will happen when you export a path in an organization or whole organization as a URI in buildomatic without the --organization flag. This will generate you a regular export archive that contains all the resources under certain URI starting from the root. Then you try to import that archive with the --organization flag. This is incorrect, you need to have consistency with these flags since --organization flag expects an archive in certain format that contains only organization data.

How to correctly export and import organization using UI:

1. Go to Manage -> Organizations

2. Right click on organization name in left panel -> export

3. On the target server go to Manage -> Organization

4. Create a new organization. Right click on that organization -> import

To correctly export and import organization using buildomatic or web services make sure you're always providing the --organization flag.

You have created a report and uploaded it to JasperReports server. When exporting that report to XLSX and opening it you get "problem with some content" error.

Solution:

This problem can be related to complex date format patterns. During XLSX export, JasperReports attempts to convert the Java date pattern into an Excel-compatible format. Since Excel cannot interpret the full pattern, the exported cell may contain an invalid numeric representatio. For example pattern like this:

EEE, d MMM yyyy h:mm a z

This is a Java pattern and it doesn't have a match in Excel. It gets transformed into something like this: 42433.5511111109 and will be the source of this error. Use simpler Excel-compatible date patterns in the report for XLSX exports. If different formatting is needed for XLSX exports specifically, consider using exporter-specific properties or conditional formatting logic for Excel output.

Image below shows the expected characters to be displayed :

There are no issues when displaying the report in java or HTML format.

Solution:

The problem was due to the font used for the textField. 

After changing the font to use a different font, for example, Adobe Heiti Std (Adobe Heiti Std R.ttf) then all the characters appear in the PDF output. 

The fonts that are used by the PDF output can be verified under File -> Properties -> Fonts tab of the PDF document.

Note: If a downloaded font is not listed, it can be added by going to Windows -> Preferences -> Jaspersoft Studio -> Fonts -> Add from Path

To debug and resolve this issue, please follow the steps outlined below:

1. Make sure to include user attributes when exporting repository content.

2. If the user already exists in the migration target repository, make sure to use update option for the import.

3. For migration of individual users, if those users have inherited profile attributes, make sure their parent users, with the attribute settings, also get migrated.

Please refer to TIBCO JasperReports^® Server Administrator Guide, chapter "Import and Export" for more information.

TTC-20181118-1648887 

User had confirmed that they are using JasperReports Server 7.1.0 themes, cleared server and browser cache, not using Internet Explorer browser with compatibility view. There's no error found in server logs and in the browser. All their users experienced this problem in various browsers.

We had ran a similar test in a JasperReports Server 7.1.0 AWS deployment with standard template but could not replicate this problem. Further investigation was focused on network traffic gathered in HAR files. What we had found is that user's network traffic for the web flow has considerably less request than the standard installation.

user's deployment web flow:

standards deployment web flow:

One thing caught our eyes is that user's deployment called jquery-ui-1.10.4-custom.css component in the web flow while the standard deployed did not. By further searching the har file content, it is determined that this component was requested in require.config.js.

After comparing require.config.js file in JasperReports Server 7.1.0 and 6.3.0 deployments, we found the root cause of the problem that user had used 6.3.0 version of JasperReports Server script files in 7.1.0 installation.

TTC-20181112

[Note: This article is valid for old JRS version 7.1 and is not repititive issue, this issue was caused by user mistakenly copied 6.3.0 version of JasperReports Server script files in 7.1.0 version. This article is not valid for latest JRS 9.0 or 10.0 vesion]

"GET /jasperserver-pro/rest/login?j_username=joeuser&j_password=joeuser" with 404
"PUT /jasperserver-pro/rest_v2/users/testme" with 401

Cause

The redirect was caused by user's account not being validated, therefore the request is redirected to the login page.

There's a known bug in JasperReports^® Server 7.1.0 for REST login request. The user needs to apply the latest JasperReports Server 7.1.0 hotfix patch package to fix this problem. Please refer to this community wiki article for detail:

https://community.jaspersoft.com/wiki/rest-v2-login-service

Resolution

User should login to their support portal account and download the latest hotfix package at:

Quote

https://support.tibco.com/s/hotfixes?id=a011a00000HJTnIAAX

Follow the instructions in readme.txt in the package to carry out the patching process. The user can proceed to test REST call to create a user as the following:

1. login request using REST_V2

    

   GET http://localhost:8080/jasperserver-pro/rest_v2/login?j_username=joesuer&j_password=joeuser
   
   

   user create request

PUT http://localhost:8080/jasperserver-pro/rest_v2/users/testme

request body:

<user>
    <emailAddress>juser@example.com</emailAddress>
    <enabled>false</enabled>
    <fullName>Joe User Test</fullName>
    <password>mySecretPassword</password>
    <roles>
        <role>
            <name>ROLE_ADMINISTRATOR</name>
        </role>
    </roles>
</user>

body type: application/XML

Please review the attached "demo.mp4" video for process detail and its result.

Alternative Work Around

If not being able to apply the hotfix at this time, user can use the following approach to work around this problem:

Do not run REST login request but run user create request directly with user credential injected through request parameters:

PUT http://localhost:8080/jasperserver-pro/rest_v2/users/testme7?j_username=joeuser&j_password=joeuser

With this approach, user can create a user account in JasperReports Server repository with a "201 Created" response or "200 OK" if this user already exists in the repository.

TTC-20181112-20190319

zoom_0.mp4

[Note : This article is only application to JRS 7.1. WIth 7.1 hotfix this issue is not facing.]

Problem Statement

We had run some tests and determined that there's a defect in TIBCO JasperReports^® Server 6.3.2 REST permission service. There's also a documentation defect relating to TIBCO JasperReports Server 6.3 REST permission service on request content format for organization affiliated permission settings.

Solution and Results

User should upgrade to at least TIBCO JasperReports Server release version 6.3.4, preferably 7.1.0, to fix this problem. The following is what we had tested and confirmed working in TIBCO JasperReports Server 6.3.4 and 7.1.0 using Chrome Poster web test tool:

Request Method: PUT

Request URL: {TIBCO JasperReports Server 6.3.4 host server}:8080/jasperserver-pro/rest_v2/permissions/organizations/jss;recipient=role:%2Fjss%2FJSS_TOP?j_username=superuser&j_password=superuser&X-REMOTE-DOMAIN=1

Request Headers:

j_username=superuser
j_password=superuser
X-REMOTE-DOMAIN=1
Content-Type=application/json

Request Content Body:

{
"uri": null,
"recipient": null,
"mask":"2"
}  

Response:

status: 200 OK
date: Thu, 18 Oct 2018 23:52:33 GMT
cache-control: private
content-type: application/xml
server: Apache-Coyote/1.1
p3p: CP="ALL"
content-length: 183
expires: Wed, 31 Dec 1969 16:00:00 PST

Response content:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositoryPermission>
<mask>2</mask>
<recipient>role:/jss/JSS_TOP</recipient>
<uri>/organizations/jss</uri>
</repositoryPermission> 

Reference: TIBCO JasperReports Server 6.4.0 REST Guide, section "Setting a Single Permission"

TTC-20181022

For example, instead of using the following expressions in the security file:

<principalExpression>
    attributesService.getAttribute('testAttribute', null, true) != null
</principalExpression>
<filterExpression>
    testProfileAttribute(table.column, 'testAttribute')
</filterExpression>

user should use:

<principalExpression>attributesService.getAttribute('testAttribute', null, true) != null</principalExpression>
<filterExpression>testProfileAttribute(table.column, 'testAttribute')</filterExpression>  

This rule applies to both profile attribute based security settings as well as role based security settings.

TTC-20180814

I created a report with table element. In that table one of the headers is split into two rows. When compiling the report the error occurs:

Height of colum header does not match row height

Solution:

Select the Cell that is split into two rows, select the cell for the upper row cell, go to cell properties and set Row Span to 2.

Note: This is specific use case and generic solution that you can try to resolve the issue