kkumlien

ProblemIn some cases in JRS, JDBC drivers will set AUTOCOMMIT to true/false (or on/off) for each new connection, with a statement looking something similar to this: alter session set autocommit=true[/code]There might be many connections for each Report depending on its design and presence of Input Controls – JNDI can help with pooling/caching connections but sometimes you might not be able to use it. You might want to disable this behaviour per specific database type / driver, because you don't need transactions or because it can have a performance impact. When AUTOCOMMIT is set, you might also see unnecessary commit or rollback statements. SolutionOne way to disable this behaviour is to add the driver Class (e.g. net.snowflake.client.jdbc.SnowflakeDriver) to the list property autoCommitUnsupportedDrivers of the bean jdbcDataSourceServiceFactory in WEB-INF/applicationContext.xml, Auto Commit will not happen and all the statements above should go away.

IntroductionGiven the long history of our products at Jaspersoft, there has been an accumulation of notions and concepts related to accessing data for reporting and visualisations. The various notions and concepts have spawn at different times in different parts of our product suite and often times they provide the same functionality although terminology is different. Our current problem when trying to support complex data access scenarios from customers is not the lack of functionality or the impossibility to fulfil a particular use case, but rather the fact that we can achieve it in different ways and there is never a clear or recommended way to proceed, which brings confusion to both customers and Jaspersoft's own PS and sales engineers. To reflect this situation, we referred to it as a soup of solutions, when it comes to accessing data for reporting and visualisations. We are going to list all the various notions and concepts and try indicate their origin and the reasons they were introduced. JR Lib Data SourceThis is probably the first concept related to data access in our products. It is represented by the JRDataSource interface in the JR Lib API and it represents tabular data used when filling a report. Various implementations of this interface exist in JR Lib and users could implement their own if they need to wrap exotic data that has a special structure and needs to be transformed into a virtual table of records with values on columns. In JR Lib, the data source is just one of the possible report parameters that one can pass to the report when filling it with data. In theory, people can generate a report without any data source or even without passing any parameter. Of course, most likely, a report not receiving any parameter and any data source is just a static, hardcoded document, which does not display any runtime value, just static labels and images. The data source parameter (REPORT_DATA_SOURCE built-in parameter) is special because it is expected to be an instance of the JRDataSource interface and it is the one that will be used by the engine to iterate through its virtual records and generate the various report sections/bands such as detail, groups headers and footers, etc. The iteration through this data source is at the core of report generating process, although a report could be generated without any data source if content is built based on parameter values alone or spawns from subreports inside a master report shell. JR Lib Query and Query ExecuterThe report data source is such an important built-in parameter, because it triggers/controls the flow of sections/bands during report generating process. But in order to fill reports using data sources, the parent application embedding the JR Lib would be responsible to provide such JRDataSource instances when calling the report filling methods. Not only that the parent application would need to contain the required logic to instantiate JRDataSource object, but it would also need to contain metadata that would keep track of the relationship between the various data source objects and the reports they go with. The parent application would need to know which data source needs to be passed to each report. This is something not easy to keep track of, especially when we are talking about deployments with more than a few dozen reports or so. With the majority of reports running against relational databases (at least in the early days of JR Lib), in was only natural to enhance JR engine so that we allow people to store an SQL query inside the report template itself. This is mostly because each report is likely to use a different query and this query probably needs to be parametrised using runtime provided values defined as report parameters. Having the SQL query inside the report template (JRXML), it means the report can instantiate a JRDataSource object on its own, simply by executing that query and wrapping the ResultSet returned through JDBC. It also means that the parent application no longer needs to instantiate the JRDataSource, but instead pass the report a different built-in special parameter called REPORT_CONNECTION, which is the JDBC connection object that the report will use to execute the query. So instead of passing a data source object to the report, we pass a connection and let the report instantiate its data source on its own by executing an SQL query from inside the report itself, through that database connection. All started with SQL queries kept in JRXML. But then people asked to be able to execute Hibernate queries (HSQL) or EJB queries (EJBQL). And this is how the notion of query executer was introduced, to indicate the fact that each type of query requires a certain way to have it executed and also requires a different set of parameters to be provided to the report in order for the query execution to succeed. The query executer in JR Lib is represented by the JRQueryExecuter interface and it is responsible for instantiating a JRDataSource object to be consumed by the report. In order to instantiate a data source, it is likely that the query executer implementation would require some predefined parameter value to be provided and would likely use that to execute some sort of query. Just as the SQL query executer needs a JDBC connection parameter to be able to execute the query, the Hibernate query executer for HSQL needs a report parameter to provide the Hibernate session object (HIBERNATE_SESSION report parameter). Same for other query executer implementations, which all have their own set of expected parameters to be able to function properly and produce the data source object. JRS Data SourceWhen we started the JasperReports Server, it started as an application using JR Lib to run reports. As explained above, JRS would have been required to: provide either a JRDataSource instance when running a reportor rely on reports having queries in them and instantiate their own JRDataSource at runtime by running those queries using pre-registered query executers.In a vanilla JRS deployment, the second approach is the default one and prevails, meaning most of the reports are expected to have SQL queries in them, while JRS will only provide the JDBC connection to them so that the reports can execute their queries through it and produce their own JRDataSource object for internal consumption during report filling process. But how does JRS provide a JDBC connection to a report? For creating a JDBC connection, any Java application needs: database server URIdatabase name,usernamepasswordJDBC driver available in the classpathThis metadata needed for JDBC connection creation is kept by JRS in a special resource in its repository and it can be used by multiple reports. Another way to get a hold of a JDBC connection object is to point to one of the connections that the application server provides through JNDI registry. In that case, the metadata need is different is mostly about knowing: the name of the JNDI entry for that particular JDBC connectionNevertheless, this metadata for acquiring a particular JDBC connection object through JNDI is also kept in a special resource in the JRS repository and can be used by multiple reports. We see that JRS is keeping the metadata needed to provide a value for the REPORT_CONNECTION parameter required by the JR Lib query executer for SQL, in special repository resources that can be reused for multiple reports that run against the same database. Probably the first terminology mistake we made in the history of Jaspersoft products was to give these resource a name that was already used for something else. We called them again: Data Source and often times in the context of JRS, we refer to them as Report Data Source, although they are different than the above explained JR Lib Data Source (JRDataSource interface). Maybe a better name for this JRS entity would have been Report Connector or in any case something that was not already present in our terminology at the time. Things started to be confusing for many JR Lib users early on because some of them were already familiar with the fact that they can create their own custom report data sources by implementing the JRDataSource, but then the notion of Custom Data Source was also introduced in JRS and was about implementing this other interface: com.jaspersoft.jasperserver.api.metadata.jasperreports.service.ReportDataSourceService Let's just say for now that a JRS Data Source is a combination between resource is a repository used to store metadataa piece of business logic that would be used to instantiate report parameter values at runtime, using the above metadataThe report parameter values produced by the JRS Data Source are normally used by the report query executer to execute the report query and thus produce the JRDataSource object eventually needed by the JR Lib engine for report filling purpose. For example, some recent implementations of JRS Data Sources are about making REST calls to remote URLs to extract XML or JSON data. Such XML/JSON data loaded from the remote location is then passed to the report filling process as built-in parameter value that either the XPath or JSONQL report query executers would recognise and use for processing. The processing is about flattening out the tree data structures and wrap them as tabular data in the form of a JRDataSource object. JR Lib Data AdapterOur report design tools always had this ability to run reports so that the users can preview their work when designing the report templates. Starting with iReport and then in JSS, we always had to have the possibility to run reports against a preconfigured database connection. That's because we've already seen that the majority of reports had SQL queries inside them. So just like JRS, it was also iR and JSS that had to provide their embedded JR Lib engine with a JDBC connection parameter when reports having SQL queries were previewed/tested. With iReport not having a repository, the metadata needed to instantiate connections through JDBC was kept in some preferences/configuration files that iReport maintained behind the scenes. This combination of metadata and business logic needed to provide JDBC connections was known as iReport Connection. So although having almost the same purpose and doing pretty much the same thing as the JRS Data Sources explained above, they were called differently when in iReport. When we moved to JSS, we wanted to perform some sort of consolidation of this terminology which is related to providing report execution with some parameter values that are elaborated based on some metadata and using business logic associated with that metadata. We realised that from a high level perspective, it seems to always be more about using some already provided report parameters values and process them to produce some additional report parameter values. And all this happens at the beginning of the report running process, before the iteration through the JRDataSource and the actual content kicks in. The figure below shows how the JRDataSource to fill a report is actually "injected" by executing the code of a DataAdapter. This "injection" is called contribution of parameters. In a similar way, figure below, a Data Adapter can contribute an instance of JDBC connection (or any other parameter) to be used to run the report query. JR Lib Parameter Contributor Parameter contributors are represented by the ParameterContributor interface in the JR Lib API and represent a generic way to provide additional report parameter values at the beginning of a report execution by leveraging already supplied parameter values. A parameter contributor implementation has access to the map of parameter values from it and can read values and contribute values back to it. Although not directly related to the data access concepts which are the topic of this presentation, it is important to mention parameter contributors here because in fact the majority of concepts presented so far can be considered parameter contributors. Query executers can be considered parameter contributors because they all use some predefined parameters that they recognize and contribute back the REPORT_DATA_SOURCE parameter value: SQL query executor uses the value of a parameter called REPORT_CONNECTION to then provide the value of a parameter called REPORT_DATA_SOURCE.Hibernate query executer uses HIBERNATE_SESSION to contribute back REPORT_DATA_SOURCE.etc.JRS Data Sources can be considered parameter contributors because they use metadata inside a repository resource and contribute back report parameter values because they have access to the report parameter values map. In fact, the ParameterContributor interface in JR Lib and the ReportDataSourceService interface in JRS are almost identical. JR Lib Data Adapters are in fact parameter contributors. The JR DataAdapterService interface in JR Lib extends ParameterContributor and only adds a test() method to it. A typical data adapter implementation in JR Lib API uses metadata from a configuration file (Java object persisted with Castor in XML format) and some business logic to contribute parameter values that would then be picked by the query executer of the report to execute the query and instantiate the report data source object. All the data access related processes that occur at the beginning of the report execution and have as ultimate goal to instantiate JRDataSource as REPORT_DATA_SOURCE parameter value, are just a series of parameter contributor actions triggered in order and each one taking over from where the previous one has left. In the figure above the user runs a report by specifying a set of parameters. A pre-configure ParameterContributor contributes a value for the parameter USER, a second ParameterContributor, actually a Data Adapter, contributes a value for the REPORT_CONNECTION parameter (with the ability, during its execution, to use any of the parameters provided up to that moment, i.e. the parameter USER). Built-in JR Lib Data Adapter Extension The JR Lib is nowadays shipped with a built-in data adapter extension that can be activated on a per report basis using a custom property in JRXML: net.sf.jasperreports.data.adapter This property is supposed to provide the URI of an XML resource (Castor XML serialization of a Java object) that would contain the metadata information to instantiate a particular data adapter implementation and trigger its parameter contribution. Using the net.sf.jasperreports.data.adapter property in a report to point to an external configuration file that has the metadata for creating and activating a particular data adapter implementation allows extracting data access metadata from the report and reuse it for several reports that have the same data access strategy, up to query execution. Reports having the net.sf.jasperreports.data.adapter property and pointing to an external data adapter configuration file are the perfect equivalent of a JRS report unit having a link (DB foreign key relationship) to a JRS Data Source resource from the JRS repository. In JR Lib deployments, there is no concept of report unit, so the link between a report and its reusable data access component (the adapter adapter configuration file) is made through this custom property in JRXML. In JRS, the report template and the reusable data access component (the JRS Data Source resource) is are glued together in a wrapping super-entity called report unit, in which relationships are kept in the forms of foreign key references between tables. JRS QueryJust as the JRS Data Source resource was used mainly to extract and isolate repeating metadata and use it with multiple reports that need to access data using the same means, it was considered that also SQL queries could be shared by multiple reports or by input controls in JRS. JR Lib itself does not have a special way to share queries among multiple reports, although this is supported by some data adapters such as the XPath or JSONQL ones, which let people specify the query inside the data adapter file and thus query execution occurs earlier, at data adapter level, not in the report. When a report unit has a reference to an external reusable query resource from the repository, it means that the query execution also happens outside normal report running process. It happens in advance, and by the time the report filling is triggered, the JRDataSource is already obtained by executing the query against the JR Data Source, separately , in advance. !!! Some limitations might exist in case the query executer relies on some runtime information (parameters or custom properties) that acquire their correct value only through normal report execution and not simplified query execution performed outside, in advance. !!! JRS Adhoc TopicWhen first introducing the adhoc designer to our user audience many years ago, we wanted people to be able to use it right away, without too much preparation work for them. An adhoc view needs to start with some query and since we did not have domains at the time, we decided to let them start creating their adhoc views using queries that they already had in their reports. It was assumed that users of JRS at the time already had some reports in their repository and these reports probably contained queries that could be used as a basis for their new adhoc views. An adhoc topic is simply a fully functional report unit which can be used as a starting point when creating an adhoc view. For a report unit to be used as adhoc topic, it needs to be placed inside a specially configured folder inside the JRS repository, which is supposed to contain only adhoc topics. The adhoc designer looks only in that particular repository folder for report units that it would then propose as adhoc topics. Initially, JRS report units and thus adhoc topics only supported SQL queries. But later on, other query languages became available to JR Lib and JRS, so the adhoc engine was enhanced to make sure report units relying on non-SQL queries would still work as adhoc topics and thus provide the raw data for the adhoc view. However, adhoc runs the topic report unit in a simplified way, in order to produce the data to fill the cache. It seems it only runs the query executer part of the whole JR Lib data access chain, which in some cases is made of multiple parameter contributor actions. This means that report units that do not use JRS Data Source but rather have a reference to a DA would not work as adhoc topics. Other limitations might exists, considering the adhoc engine does not perform a normal report execution when using the topic to extract the data for fuelling its initial adhoc cache. JRS Data Source vs JR Lib Data AdapterJRS Data Source Pros has support for UI editors in JRSCons does not exist outside JRScannot be assigned to subreports and thus do not allow subreports to connect to a data source different than the one of the masterJR Lib Data Adapter Pros works everywhere JR Lib is deployed, including custom applications, JSS and JRSonce a DA created and tested in JSS, it can be deployed as resource in JRS as-is and works right awayhas pluggable custom editors in JSSeach JRXML (dataset/subdataset) can point to its own data adapter, which allows subreports/subdatasets to connect to different databases, than the masterCons does not have an UI for editing in JRScan't be used for filling list Input Controls in JRSreport units with DA cannot be used as adhoc topic in JRS

ProblemWhile running one of the manual installation steps of JasperReports Server (https://community.jaspersoft.com/documentation/tibco-jasperreports-server-installation-guide/v790/installing-war-file-manually), for example: ./js-ant import-minimal-pro you get this nested error / exception (towards the bottoms of the stack trace): Error creating bean with name 'keystoreManager': Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class com.jaspersoft.jasperserver.crypto.KeystoreManager$InstanceHolderSolutionEven though the JAR file containing the KeystoreManager class is available in the classpath – for example buildomatic/lib/js-crypto-3.1.0.jar – and the ks and ksp variables are set correctly in buildomatic/keystore.init.properties, you might still need to add the directory path(s) of the Keystore files as environmental variables in the command itself per the example below. Please REPLACE the path /opt/tomcat with the actual path(s) where your keystore files .jrsks and .jrsksp are located. If they were not present already, they would have been generated in one of the previous installation steps. ks=/opt/tomcat ksp=/opt/tomcat ./js-ant import-minimal-pro When running JasperReports Server in Tomcat or other app server, it might also work to pass those as JVM properties, for example: -Dks=/opt/tomcat -Dksp=/opt/tomcat Further investigation is required on why in some cases they might not be read correctly from the properties files, but the above approach should help for now.

ProblemYou need to connect VisualVM to extract performance data from a JasperReports Server instance running on Kubernetes, as explained in the article Capturing Detailed Middle Tier Performance and State Information, but you don't have direct access to the pod or the port is not exposed. SolutionAssuming you want to run JMX on TCP port 9999, which should not be already in use on either: pod host, master node, nor you local host. Please BE AWARE of the security implications, you will want to open the JMX port only to specific trusted hosts. 1. On the pod – configure JMX as per article Capturing Detailed Middle Tier Performance and State Information. You might need to use Tomcat level customizations, as explained in https://github.com/TIBCOSoftware/js-docker#jasperreports-server-volumes or to customize your Docker build. 2. On the master node – forward the pod's port locally, for example: kubectl port-forward --address 0.0.0.0 <pod/mypod> 9999[/code]The --address 0.0.0.0 option allows the master node to listen on all addresses / interfaces. 3. On your local host – run an SSH tunnel to the master node, for example: ssh username@master-node -L 9999:127.0.0.1:9999[/code]4. On your local host – connect VisualVM locally, for example: visualvm --openjmx localhost:9999[/code]Further details and demo to be added here soon.

Please see this recorded Dr Jaspersoft webinar for a live demo (although mostly focused on 7.8.0 and later versions): In this article we present a sample configuration for Cross-Origin Resource Sharing in JasperReports Server version 7.5.1 and earlier versions. In 7.5.1 and earlier versions, this configuration is different and separate from the domainWhitelist mechanism, which is still required for the Visualize.js API. For 7.8.0 and later versions, please follow the instructions in CORS for Visualize.js. as in those versions the configuration of the two is merged together in the domainWhitelist mechanism. Assuming there is no CORS-specific configuration in your Tomcat (or other app server) web.xml file, below you can find a sample config for JRS' specific apache-tomcat/webapps/jasperserver-pro/WEB-INF/web.xml. Please notethe location / sorting of the beans is important, follow the example below to avoid issuesthe values in this sample configuration are copied from the applicationContext-security-pro-web.xml file of a vanilla 7.8.0 configuration, yours may vary depending on your specific requirementsthe sample below is based on a vanilla 7.5.1 configuration, yours may be different if it's a different version or you have previously modified the fileit is not recommended to set cors.allowed.origins to * (any origin), especially in a production environment, rather set it to empty / blank if no access is required from any external origins – this is the same as not having a CORS filter at all defined in your configuration, which prompts browsers to stick to the default restrictive behaviourif cors.support.credentials is set to true (as recommended) you will not be able to set cors.allowed.origins to * (the application will not start)InstructionsComment out the existing filter (around line 209) and add one based on the standard Catalina class. Review the Tomcat syntax documentation for details. Replace the cors.allowed.origins values below with the actual origin(s) as required in your application architecture. <!--filter> <filter-name>CorsFilter</filter-name> <filter-class>com.jaspersoft.jasperserver.api.security.csrf.CorsFilter</filter-class> </filter--> <filter> <filter-name>CorsFilter</filter-name> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class> <init-param> <param-name>cors.allowed.origins</param-name> <param-value>https://www.example.com, https://www.example.net</param-value> </init-param> <init-param> <param-name>cors.allowed.methods</param-name> <param-value>GET,POST,HEAD,PUT,OPTIONS,DELETE,PATCH</param-value> </init-param> <init-param> <param-name>cors.allowed.headers</param-name> <param-value>Cache-Control,X-Suppress-Basic,Origin,Accept,X-Requested-With,Content-Type,Pragma,accept-timezone,withCredentials,X-Remote-Domain,X-Is-Visualize,x-jrs-base-url,Content-Disposition,Content-Description</param-value> </init-param> <init-param> <param-name>cors.exposed.headers</param-name> <param-value></param-value> </init-param> <init-param> <param-name>cors.support.credentials</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>cors.preflight.maxage</param-name> <param-value>300</param-value> </init-param> </filter>Then (around line 358) add a filter-mapping for CorsFilter, after CrossDomainFilter and before the other existing CorsFilter mappings specific to fonts. <filter-mapping> <filter-name>CrossDomainFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CorsFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CorsFilter</filter-name> <url-pattern>*.woff</url-pattern> </filter-mapping>As usual, please restart the app server after making these changes. E.g. for macOS: /Applications/jasperreports-server-7.5.1/ctlscript.sh restart tomcatIf the application doesn't start correctly, there are probably syntax errors or typos in the modified file(s). Test CORS requests via JavaScriptA simple way to test your CORS configuration is to use JSFiddle, see for example: https://jsfiddle.net/kkumlien/4Lx15mqe/2/ Before you allow the JSFiddle domain origin in the configuration, the request should fail and you should see something like this in the browser developer tools: After setting cors.allowed.origins to http://fiddle.jshell.net, https://fiddle.jshell.net, you s hould see something like: Please do not use the JSFiddle origins above in a production / public instance of JRS, but only in a development / test environment. Test CORS requests via cURLPlease see the attached file CORS-cURL.txt for some sample tests you can do directly via the `curl` command. cors-curl.txt