About Logi Apps and Java
Logi Info v12 can produce web applications that use either the .NET Framework or Java libraries. Logi Java applications can be run on web servers under Linux and other UNIX variants, as well as under Windows.
- About Logi Reporting with Java
- General Requirements
- Product Licensing
- Differences from Applications for .NET
- Sharing Session Variables with Other Apps
- Cross-site Scripting (XSS) Protection
About Logi Reporting with Java
Logi Info consists of two parts: LogiStudio and the LogiServer Engine. When a Java application type is selected during development, Studio generates applications that use the JDK libraries rather than the .NET framework. The Server Engine includes special components that allow Logi applications to be deployed as Java applications on Windows or Linux/UNIX platforms.
The process of creating Logi applications is identical regardless of which application type, Java or .NET, is desired. Some specialized elements that are included to support the Java environment are available, such as Connection.JDBC, when developing Java applications.
The formats of definition, support, and other files that make up a Logi application and are created by developers are the same for all versions of Logi managed reporting products.
Logi Studio, though Java-aware, is a Windows application. Developers creating Logi apps use Studio on a Windows PC to develop their Logi applications, regardless of the final deployment environment. Developers have the option of developing and testing their application entirely on a Windows platform before moving it to a production Linux/UNIX server.
Logi applications can be deployed on servers running Windows or Linux/UNIX. A Logi application can be moved to one of these servers and enabled to use the JDK by adding special folders to the application folder (changes in the _Settings definition, such as the application path and connection attributes, may also be necessary).
Please review the following requirements carefully to ensure that your hardware and software are suitable:
We do not have specific hardware configurations to recommend for use with the product. Logi Studio can only be installed on 64-bit Windows platforms. Logi Info is only available in a 64-bit version. Logi Java applica-tions must also be run 64-bit Linux/UNIX platforms. For information on sizing for performance, see System Requirements - Logi Info.
Review System Requirements - Logi Info to ensure that your web server and other software are supported.
Oracle JDK or OpenJDK
Oracle has changed its Java usage policies - please read our Java Usage Policy for important information.
The official Oracle Java Development Kit or OpenJDK 7, 8, 11, 12, 13, or 14 (Info v12.6 SP2+ required for 11+) is required for Logi Java applications, as it includes the Server JVM and will provide faster performance. You must install the JDK on the web server, the JRE is not sufficient.
Database Connectivity and Tools
Connectivity to databases such as Oracle, MySQL, and MS SQL Server is supported via native connections. Connections using JDBC are also available. Connections to a variety of non-database datasources are also supported, including XML, CSV, Excel data files, and web services.
Specific MySQL and MS SQL Server database drivers are provided with the Logi Server Engine, so developers do not need to separately download and install them. However, these may not be the correct version for all circumstances and developers may need to update or replace them.
Our SQL Server JDBC driver works with JDK or OpenJDK 8, and (Info v12.6 SP2+) 11, 12, 13, 14 and MS SQL Server 2005+. The previous version of the driver's sqljdbc4.jar file, however, is still provided, as sqljdbc4.old, for users who work with MS SQL Server 2000.
Developers working with Oracle, who wish to use the Database Browser and Query Builder tools within Studio, may need to install and configure the Oracle Client (OLEDB) on the Windows platform where Logi Studio is installed.
Required Platform Knowledge
Developers creating Logi Java applications for Linux/UNIX servers should ensure that they have a good working understanding of the OS, the JDK, the web server, and the admin/management tools on their server. The detailed knowledge required to successfully administer the servers can be extensive and complex and is well beyond the scope of Logi documentation.
Logi Info v12+ comes with a built-in, 15-day trial license. You need do nothing but install the product and you can begin using it. A clearly-visible display in Studio's toolbar counts down the days remaining in the trial period.
Clicking the counter display will take you to a web page that offers information about purchasing a regular Logi license.
After the trial period expires, Studio and any Logi reports you may have developed will no longer run without a valid license.
You may not use our products for redistribution with, or embed them in, other products without an OEM license; contact our Sales group for more information if you need an OEM license.
For more detailed information about licenses, see our document Product Licensing.
Logi Java applications provide all of the features and functionality found in Logi .NET applications.
Naturally, Logi Java apps do not support Windows-specific technologies such as OLEDB. Analogous Java technologies, such as JDBC, are supported instead. However, for the best results, developers should try to use native connections, such as Connection.MySQL, before using generic connections like Connection.JDBC.
- Any OLAP elements (note that XOLAP elements, however, are supported)
- DataLayer.Web Scraper
For information about installing Logi Studio, see our document Install Logi Info for Java Development.
For information about deploying Logi Java applications, see our document Java Server Configurations.
On a web server, Logi applications for Java and regular (non-Logi) Java applications maintain their session variables in different ways. And, typically, Logi application session variables are accessed using @Session tokens, while Java application session variables are accessed via JSP or by using the javax.servlet.http.HttpSession object.
If a Logi application for Java is to be integrated with a Java application, then how can their session variables be shared? The Java Session Copying element, available in the _Settings definition, provides a selective method for session variable copying between the two applications.
In order to use this feature, you must not use session variable names that contain spaces in your Logi application, and there's a small performance penalty for this process, so it's best to minimize the number of variables copied. It may be necessary to restart your web server if you edit the lists in the attributes described below.
The element has four attributes, consisting of Regular Expressions, which control which session variables are copied. As it can be difficult to write Regular Expressions which both include and exclude strings, we've provided two attributes ("include") which are processed first, followed by two other attributes ("exclude") which are processed second, making it easier to accomplish both types of operations.
|Copy From Java Exclude||Specifies, as a comma-separated list of Regular Expressions, the Java application session variables that will not be copied to the Logi application session variable space. This attribute is processed after Copy From Java Include, removing variables from that list.|
|Copy From Java Include||Specifies, as a comma-separated list of Regular Expressions, the Java application session variables that will be copied to the Logi application session variable space.|
|Copy To Java Exclude||Specifies, as a comma-separated list of Regular Expressions, the Logi application session variables that will not be copied to the Java application session variable space. This attribute is processed after Copy To Java Include, removing variables from that list.|
|Copy To Java Include||Specifies, as a comma-separated list of Regular Expressions, the Logi application session variables that will be copied to the Java application session variable space.|
Cross-site scripting (XSS) is a common form of security vulnerability affecting web applications. Attackers use XSS to inject client-side scripting into web pages via the URL, tricking the browser into trusting scripts run from malicious hosts. These scripts usually access user and session information stored in cookies, and allow the hackers to forge trusted user behavior. Most modern browsers include a defence against this, the X-XSS-Protection header, which is enabled by default. However, this may not satisfy penetration testing and applications may be determined to be vulnerable. Beginning with early versions of Info v12, Logi applications can be configured to enable XSS Filtering at the web server, as follows:
Once copied, session variables are identified, in the Java app, using its session object's attribute ID and, in the Logi app, as the name used with a @ Session token. For example: Java JSP: session.getAttribute("userEmail")
Logi app: @Session.userEmail~
If circumstances demand it, it's possible to return to an earlier, "copy all" behavior by manually adding the following XML to your _Settings definition source code, as a child of the <Setting> tag:
<JavaSessionCopying CopyToJavaInclude="^" CopyToJavaExclude="DebugFile,-bUsesSort$,-tra$,-xmlDef$,
-Xsl$,-rdDef$" CopyFromJavaInclude="^" CopyFromJavaExclude="^rd,^dt" />
- Edit the <yourLogiApp>\WEB-INF\web.xml file and uncomment the code section that begins with:
<filter-name>XssFilter</filter-name> Save the file.
- Edit the <yourLogiApp>\WEB-INF\XssFilter.properties file and provide appropriate filtering directives.
As installed, the default XssFilter.properties file includes six directive examples. Delete them and add:
filter2=,)<>!(@,POST The effect of the examples above is to throw an error and not execute any page requested with GET or POST using any URL that includes any of these characters: ()<>!@ . The format of a filter directive consists of three parts:
filter#= urlPattern , forbiddenCharacters , requestType
urlPattern = the URL, for example "rdReport=Default"; leave this blank to apply the filter to all URLs
forbiddenCharacters = the characters in the URL that will cause an error; leave this blank to allow all characters
requestType = HTTP request type: either GET or POST Here's another example:
This example filters URLs requested using POST and containing "rdReport=yourCustomReport" and it allows all characters.
Prior to v12.5 SP2, filters could require a large number of directives to cover all the possibilities, and these might have conflicted with URLs generated by super-elements such as the Analysis Grid. After that release, this is handled internally and one or two directives like the first two shown above are sufficient to provide broad, generic protection in most cases.