Application Server-related Problems

Memory Issues Running Under Tomcat

If you experience problems related to the release of memory or to container tag pooling, the following steps might solve the problem:

enablepooling = false

Java Out of Memory Error

If you encounter a Java out of memory error, try increasing your Java heap size setting. See Setting JVM Options for Application Servers. As a minimum, add -Xms1024m -Xmx2048m to your JAVA_OPTS setting.

This Java option is set within the application server, so you must set it then restart your application server.

Configuration File Locations

JasperReports Server configuration properties are found in the following files, depending on your application server.

The following list shows the location of the properties for supported application servers:

Context.xml under Tomcat: Special Case

If you deploy multiple instances of JasperServer to Tomcat, the context.xml (database connection configuration) can be superseded by a file in this location:  <tomcat>/conf/Catalina/localhost/jasperserver.xml file. This is the case with some Tomcat versions before Tomcat 7.

When JasperServer is deployed, the context.xml will be copied to <tomcat>/conf/Catalina/localhost/jasperserver.xml (Tomcat does this by default).

Now, if you make changes to your <tomcat>/webapps/jasperserver/META-INF/context.xml, Tomcat will not “see” them. Instead, the jasperserver.xml will be used. This is confusing, but is the way that Tomcat operates.

If you edit your context.xml to fix a database problem:

<tomcat>/webapps/jasperserver/META-INF/context.xml

Remember to delete the jasperserver.xml file:

<tomcat>/conf/Catalina/localhost/jasperserver.xml           (delete this file)

Tomcat 6 Installed Using apt-get

If you are installing JasperReports Server to an instance of Tomcat that has been installed using a package manager such as apt-get, yum, or rpm then you can use the CATALINA_HOME and CATALINA_BASE properties found in your default_master.properties file.

Go to the section of the default_master.properties that looks like this:

# Tomcat app server root dir
appServerDir = C:\\Program Files\\Apache Software Foundation\\Tomcat 7.0
# appServerDir = /home/devuser/apache-tomcat-7.0.26
# if linux package managed tomcat instance, set two properties below
# CATALINA_HOME = /usr/share/tomcat6
# CATALINA_BASE = /var/lib/tomcat6

and change it to the following:

# Tomcat app server root dir
# appServerDir = C:\\Program Files\\Apache Software Foundation\\Tomcat 7.0 
# appServerDir = /home/devuser/apache-tomcat-7.0.26
# if linux package managed tomcat instance, set two properties below
CATALINA_HOME = /usr/share/tomcat6
CATALINA_BASE = /var/lib/tomcat6

Note that you must set both CATALINA_HOME and CATALINA_BASE.

Installing on tc Server

If you are installing JasperReports Server to an instance of Pivotal tc Server, you can follow the directions for Tomcat installation in Installing the WAR File Using js-install Scripts, with the following modifications:

...

# Tomcat app server root dir
appServerDir = <tc-home>/<js-instance>

In this example, your tc Server instance is installed to <tc-home> and <js-instance> is the subdirectory where you want to install JasperReports Server.

On Windows:

On Linux:

See Setting JVM Options for Application Servers for more information.

GlassFish Modifications

Using a Custom Domain

If your application server is GlassFish and you’re using a custom domain, set up the following authentication information in the default_master.properties:

# Glassfish domain name (default is domain1)
glassfishDomain=domain1
 
# Glassfish domain port (default is 4848), user (default is admin) and password.
# Uncomment and set up next parameters if you install JasperServer to the custom Glassfish domain (not default)
#glassfishPort=4848
#glassfishUser=admin
#AS_ADMIN_PASSWORD=adminadmin

Using GlassFish 3.1.0

There is a known issue with GlassFish 3.1.0 where Java JVM options are not properly set. This issue is fixed in GlassFish 3.1.1 and later.

To set the JVM options in GlassFish 3.1.0:

<js-install>/buildomatic/default_master.properties

glassfishPort=4848

Can’t Upload Files on GlassFish 3.1.2

There is a known issue with file upload on GlassFish 3.1.2 which prevents you from uploading files to the JasperReports Server (GLASSFISH 18446). This issue is resolved in the 3.1.2.2 release, which is a microrelease that resolves this and other critical issues.

Requests to Single Permissions REST2 Service fail on GlassFish

Requests to Single Permissions REST2 service are failing on GlassFish with the following error:

400 Invalid URI: Encoded slashes are not allowed by default. To enable encodedslashes, set the property com.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true

To fix this issue, perform the following command:

./bin/asadmin create-jvm-options -Dcom.sun.grizzly.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

BufferOverflowException When Working With Input Controls

In some cases, when you adding a large number of values to an input control, you may see an overflow error such as the following:

Request URI is too large.

java.nio.BufferOverflowException

To fix this issue, increase the allowed URI size in the GlassFish admin console. Go to Configurations > cluster-config > Network Config > Transports > tcp > Buffer Size and increase the value to 131072 or more.

JBoss Modifications

JBoss 7 Startup Error

JBoss 7 has a default startup time period. If your JBoss 7 takes longer than 60 seconds to startup or deploy, you may receive the following error:

“(DeploymentScanner-threads - 1) Did not receive a response to the deployment operation within the allowed timeout period [60 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment”.

To fix this, you need to increase your deployment-timeout setting as follows:

cd <jboss>/standalone/configuration

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">

<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>

</subsystem>

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">

<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="600"/>

</subsystem>

On server restart, your system will have the specified amount of time to start up.

JBoss 7 ReservedCodeCacheSize Error

If you get a fatal error similar to the following:

"out of space in CodeCache for adapters"

This might be the result of too low a memory setting for the ReservedCodeCacheSize flag. This error has been observed when running the Oracle JDK, version 1.6.

You can increase the value of this flag by setting a higher value such as shown in the example below:

Linux

export JAVA_OPTS="$JAVA_OPTS -DReservedCodeCacheSize=128m"

Windows

set JAVA_OPTS=%JAVA_OPTS% -DReservedCodeCacheSize=128m

JBoss Large INFO Log Message on Drill-through

JBoss has an internal mechanism to track and log information on unclosed JDBC connections. Jaspersoft OLAP Views leaves a connection open for performance reasons when doing a drill-through. In this case, JBoss puts a large INFO level message into the server.log.

To silence this INFO message, perform these steps:

<jboss>/server/default/conf/jboss-log4j.xml

<category name="org.jboss.resource.connectionmanager.CachedConnectionManager">
<priority value="WARN"/>
</category>

JBoss 5.0.1 and 5.1.x Error

With JBoss 5.0.1 and 5.1.x, you might see the following error:

org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser

Caused by: java.lang.ClassCastException

This error might have occurred with older releases of JasperReports Server. Newer releases use a jar newer than 2.7.1 so this problem should not occur. Additionally, the xercesImpl-*.jar is automatically deleted when installing using the buildomatic scripts.

This is a class conflict with the xercesImpl-2.7.1.jar in JasperReports Server. To correct it, delete the following file:

<jboss>/server/default/deploy/jasperserver.war/WEB-INF/lib/xercesImpl-*.jar

AttachmentStore Error in JBoss 5.1

With JBoss 5.1 you might see the following error:

DEPLOYMENTS IN ERROR:

Deployment “AttachmentStore” is in error due to: java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]

This is a known JBoss issue. The resolution is to edit the file jboss-5.1.0.GA\server\default\conf\bootstrap\profile.xml to include java.io.File:

<bean name="AttachmentStore"
      class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
  <constructor>
    <parameter class="java.io.File">
      <inject bean="BootstrapProfileFactory" property="attachmentStoreRoot"/>
    </parameter>
  </constructor>
  <property name="mainDeployer">
    <inject bean="MainDeployer" />
  </property>
  <property name="serializer">
    <inject bean="AttachmentsSerializer" />
  </property>
  <property name="persistenceFactory">
    <inject bean="PersistenceFactory"/>
  </property>
</bean>

Using a Non-default JBoss Profile

If your application server is JBoss and you’re using a profile other than the default, you need to set the jboss.profile property before running the js-install script in Installing the WAR File Using js-install Scripts:

<js-install>/buildomatic/build_conf/default/app.srv.properties

from

# jboss.profile = default

to

jboss.profile = <your_profile>

Using JBoss with Non-Latin Characters

If your application server is JBoss, and your organization is created with non-Latin characters, you will need to edit the standalone.xml configuration file.

......
</extensions>
 
<system-properties>
  <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
  <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
</system-properties>

JBoss 4.2 XML/A Connection Fix

JBoss 4.2 includes the JBossWS service as a standard, default feature. JasperReports Server has web services support for XML/A connections.

The web services classes in JasperReports Server and JBoss can conflict and cause the following error when attempting to utilize a JasperReports Server XML/A connection:

javax.xml.soap.SOAPException: Unable to create message factory for

SOAP: org.jboss.ws.core.soap.MessageFactoryImpl

To prevent the web services class conflict, set the special Java JVM options for JBoss 4.2, as described in Tomcat and JBoss JVM Options.

Disabling User Session Persistence in Application Servers

JasperReports Server stores non-serializable data in its user sessions, which can cause errors after restarting your application server:

Exception loading sessions from persistent storage

Cause: java.io.NotSerializableException ...

The errors appear in the JasperReports Server log when users log in after the application server has been restarted. The errors do not appear to users, and they have no impact on JasperReports Server operations.

Because JasperReports Server user sessions are not persistent, you can configure your application server to disable persistence and avoid the error. For example, in Apache-Tomcat 5.5, 6, and 7 edit the file <tomcat>/conf/context.xml and locate the following lines:

<!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <!--
    <Manager pathname="" />
    -->

Remove the comment markers from lines 2 and 4 above, then restart Apache-Tomcat for the change to take effect. For other application servers, refer to the product documentation.

Session Error Using JasperReports Server and Tomcat 7

On some versions of Tomcat 7, a session error might occur while running reports, with the log error “A request has been denied as a potential CSRF attack.” This is due to a known conflict between security settings in Direct Web Remote library (DWR) 2.x and some versions of Tomcat 7.0.x:

To work around this problem, you must modify these safeguards by doing one of the following:

OR

For more information on the security impact and relative risks of these two choices, see, for example, the Cross-site Scripting and Cross-site Request Forgery pages at the Open Web Application Security Project (OWASP).

Disabling httpOnly for Cookies in Tomcat

The application server that hosts JasperReports Server handles the session cookie. To prevent malicious scripts on a client from accessing the session cookie, and thus the user connection, Tomcat 7 is set to use httpOnly cookies. This tells the browser that only the server may access the cookie, not scripts running on the client. When enabled, this setting safeguards against XSS attacks.

You can disable this by setting httpOnly in the file <tomcat>/conf/context.xml:

<Context useHttpOnly="false">
...
</Context>

Allowing Requests from Other Domains in DWR

DWR is a server-side component used for Input Controls. By default, DWR uses session ID cookies to prevent against cross-site request forgery. You can disable the protection in DWR by setting the crossDomainSessionSecurity parameter for the dwr servlet in the file <tomcat>\webapps\jasperserver\WEB-INF\web.xml:

<servlet>
    <servlet-name>dwr</servlet-name>
<servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
    ...
    <init-param>
      <param-name>crossDomainSessionSecurity</param-name>
      <param-value>false</param-value>
    </init-param>
  </servlet>