[FRS-448] Securing FusionReactor and jsp applications in tomcat using LDAP


Overview

FusionReactor provides different types of user accounts (Administrators/Manager/Observer), however, if you would like to restrict access to FusionReactor for individual users, you can do this via LDAP authentication.

This technote will guide you through configuring tomcat to use LDAP authentication to restrict access to both FusionReactor and your JSP applications.

We will split this guide into 5 distinct sections

  1. Configuring LDAP
  2. Configuring the server.xml file
  3. Configuring the JSP application
  4. Configuring the FusionReactor web root
  5. Disabling the external web root of FusionReactor

1.  Configuring LDAP

When configuring LDAP for use with tomcat you are required to create a collection of individuals and a collection of groups (one group per required tomcat security role), each user can be assigned to one specific group

In this example, FusionReactor and the JSP application are assigned to separate tomcat roles. The domain structure is as follows

dn: dc=mydomain,dc=com
objectClass: dcObject
dc:mydomain

dn: ou=people,dc=mydomain,dc=com
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=mydomain,dc=com
objectClass: organizationalUnit
ou: groups

dn: uid=jsmith,ou=People,dc=mydomain,dc=com
objectClass: inetOrgPerson
uid: jsmith
cn: John Smith
sn: Smith
userPassword: myPassword

dn: uid=ajones,ou=People,dc=mydomain,dc=com
objectClass: inetOrgPerson
uid: ajones
cn: Adam Jones
sn: Jones
userPassword: myPassword

dn: cn=fusionreactor,ou=groups,dc=mydomain,dc=com
objectClass: groupOfUniqueNames
cn: fusionreactor 
uniqueMember: uid=jsmith,ou=People,dc=mydomain,dc=com

dn: cn=myApplication,ou=groups,dc=mydomain,dc=com
objectClass: groupOfUniqueNames
cn: myApplication
uniqueMember: uid=ajones,ou=People,dc=mydomain,dc=com

 You could instead create one group for example "admin" and use this for FusionReactor and the JSP application.

2. Configuring the server.xml file

Tomcat in its default installation will use a local database to authenticate user access, we need to modify the server.xml file typically located at {Tomcat Root Directory}/conf/server.xml so that tomcat will instead use the LDAP server as it's authentication service.

To do this first open the server.xml file in a text editor, you should replace the default Realm element tag:

<Realm className="org.apache.catalina.realm.LockOutRealm">
   <!-- This Realm uses the UserDatabase configured in the global JNDI
        resources under the key "UserDatabase".  Any edits
        that are performed against this UserDatabase are immediately
        available for use by the Realm.  -->
   <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
        resourceName="UserDatabase"/>
</Realm> 

With the following:

<Realm   className="org.apache.catalina.realm.JNDIRealm"
  connectionURL="ldap://myDomain.com:389"
  userPattern="uid={0},ou=people,dc=myDomain,dc=com"
  roleBase="ou=groups,dc=myDomain,dc=com"
  roleName="cn"
  roleSearch="(uniqueMember={0})"
/>

More information on realms can be found here: https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html

3.  Configuring the JSP application

By default any application you place in the webapps directory of tomcat will be accessible without authentication, however, you may have an application that should only be accessible to a specific user, you can achieve this by modifying the web.xml file of the application this can usually be found at {Tomcat Root Directory}/webapps/{App Name}/WEB-INF/web.xml

Within the "web-app" element tag add the following:

<security-constraint>
   <web-resource-collection>
      <web-resource-name>FusionReactor</web-resource-name>
      <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
      <role-name>myApplication</role-name>
   </auth-constraint>
</security-constraint>
<login-config>
   <auth-method>BASIC</auth-method>
   <realm-name>SecuredApp</realm-name>
</login-config>

This will block any user with an unauthorized role from accessing your application, it is possible to define multiple authorized roles my duplicating the "role-name" element tag for example:

<auth-constraint> 
     <role-name>myApplication</role-name> 
     <role-name>fusionreactor</role-name> 
</auth-constraint> 

4. Configuring the FusionReactor web root

 With the default configuration of FusionReactor, you will be able to access the Application Performance Monitor through either the application server port (external port), 8080 for tomcat, or the instance port defined in the java arguments (internal port). Accessing FusionReactor through the external port uses the web root, the path to FusionReactor on the port.

By default, this is "/fusionreactor/" so if the internal port is enabled you will be able to access your FusionReactor instance at http://localhost:8080/fusionreactor/. 

You can change this value by navigation to FusionReactor > Settings > Web Root:

 

To configure LDAP security you will first need to create the following web app directory structure:

 ensuring you replace "fusionreactor" with your web root.

Your web.xml file should contain the following:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                             http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">        <security-constraint>
        <web-resource-collection>
          <web-resource-name>FusionReactor</web-resource-name>
          <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
           <role-name>fusionreactor</role-name>
        </auth-constraint>
      </security-constraint>
       <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>SecuredApp</realm-name>
      </login-config>
</web-app> 

This will ensure that any user that does not have the tomcat role fusionreactor cannot access the instance.

At this stage, you will be able to test that both your application and FusionReactor authentication access is working as expected

5. Disabling the external web root of FusionReactor

Although your external port is now secured FusionReactor is still accessible over the internal port without LDAP authentication, to stop this we simply need to disable the external port.

You can do this in 2 ways:

  1. In the settings page
    1. Simply disable the port
  2. In the java arguments
    • Windows – Run the tomcatw.exe application within {Tomcat Directory}bin
    • Linux – Open the setenv.sh file in a text editor this file should be located at {Tomcat Directory}/bin/setenv.sh

                 In the -javaagent argument remove the address={port number} configuration option, for example:

                -javaagent:/opt/fusionreactor/instance/tomcat7/fusionreactor.jar=name=tomcat7,address=8098 will become –javaagent:/opt/fusionreactor/instance/tomcat7/fusionreactor.jar=name=tomcat7           

Conclusion     

After following the above steps we should now be in the following state:

  • An unauthorized user cannot access either the JSP application or FusionReactor
  • To Authenticate a user your LDAP server will be contacted
  • Only users with appropriate tomcat roles will be able to access the JSP application of FusionReactor
  • FusionReactor will not be accessible on the internal port

Issue Details

Type: Technote
Issue Number: FRS-448
Components:
Environment:
Resolution: Fixed
Last Updated: Today 11:45 AM
Affects Version:
Fixed Version: None
Server: Tomcat
Platform:
Related Issues:

[frs-386] Network IO Graph can show negative values if a server enters sleep mode


When a sever falls into sleep mode the Network IO Graph may show negative values. The Network IO Graph is located in FusionReactor under:

  • System Resource > Network Usage

Network IO Graph displaying negative spikes in FusionReactor

Negative values will cause the 1 Hour, 1 Day, and 1 Week graphs to display incorrectly where the negative values occurred.

FusionReactor will be fixed by preventing the negative values in a later release.

Issue Details

Type: Technote
Issue Number: FRS-386
Components: Metrics
Environment:
Resolution: Fixed
Last Updated: 23/Feb/16 3:40 PM
Affects Version: 6.0.0, 6.0.1, 6.0.2, 6.0.5
Fixed Version: 6.x
Server: BlazeDS, ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, ColdFusion 10, Flex Data Services, GlassFish, JBoss, JBoss 7, Jetty, JRun 4, Open BlueDragon, LiveCycle Data Services, Railo, Resin, ServletExec, Tomcat, Tomcat 7, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-339] Tomcat: GZip Response Compression Stalls Download


This technote describes an issue with the FusionReactor Compressor when used with Tomcat.

Description

With FusionReactor > Compression Settings > Compression Support > GZIP Response set to Enabled, you may see resource delivery stall for up to 20s.

This occurs only in static content, whose length can be definitively known in advance, such as .gif, .jpg, .html and .css files.

Analysis

When delivering a file, the Content-Length header is set by Tomcat to be the original (uncompressed) size of the file, regardless of whether the content is being compressed or not.

The effect of this is that the compressor finishes delivering the content much sooner than the browser expects. Tomcat then keeps the connection open for up to 20s (this value may change based on your local configuration and Tomcat version) in Keepalive mode, in case any more content can be pipelined without reopening the connection.

When Tomcat closes the connection after 20s, the browser assumes the received size is the actual content length, and processes it.

Workarounds

  • Use FusionRector's Compression > Exclude URLs and MIME Type Restrictions to specifically exclude certain paths and types from the compressor.
  • Turn off Keepalive in Tomcat (see here) by adding the maxKeepAliveRequests=1 in the Connector section of Tomcat's server.xml file.
  • FusionReactor 5.2.0 and Later: add the line gzip.content_length_workaround.active=true to your instance's reactor.conf file, taking care not to change any other lines in this file. A JEE container restart will be required.

The last workaround, introduced in 5.2.0 and later, causes FR to send a Content-Length of -1, requiring tomcat to compute the header itself.

Warning: If the compressed response does not fit within a single Tomcat buffer (in Tomcat 8, currently 8192 bytes), Tomcat will fall back to the old behaviour, calculating the Content-Length from the original file size, again causing a stall.

Issue Details

Type: Technote
Issue Number: FRS-339
Components: Compression
Environment:
Resolution: Fixed
Last Updated: 05/Aug/14 4:17 PM
Affects Version:
Fixed Version: 5.2.0
Server: Tomcat
Platform:
Related Issues:

[frs-155] I have forgotten the login password for FusionReactor. Is there any way to retrieve or reset the password without reinstalling the software?


If you have access to the computer where FusionReactor is installed you can reset the password without uninstalling and reinstalling FusionReactor as follows:

FusionReactor 1 + 2

  1. Find the FusionReactor configuration file (reactor.conf) of the instance for which you want to reset the password.
    For FusionReactor 1.0 this is typically C:FusionReactorconfreactor.conf on Windows or /opt/fusionreactor/conf/reactor.conf on Unix.
    For FusionReactor 2.0 this is typically C:FusionReactorinstance<your instance name>confreactor.conf on Windows or /opt/fusionreactor/instance/<your instance name>/conf/reactor.conf on Unix.
  2. Open the configuration file with an editor and replace the value of the property password with D41D8CD98F00B204E9800998ECF8427E. The resulting line must look like this
    password=D41D8CD98F00B204E9800998ECF8427E
    
  3. Restart the application server, and then you can log in to FusionReactor by hitting return (leave the password blank).
  4. Remeber to set a new password immediately from the FusionReactor menu : Change Password option.

FusionReactor 3, 4 & 5

  1. Find the FusionReactor configuration file (reactor.conf) of the instance for which you want to reset the password. This is typically C:FusionReactorinstance<your instance name>confreactor.conf on Windows or /opt/fusionreactor/instance/<your instance name>/conf/reactor.conf on Unix.
  2. Open the configuration file with an editor and edit the value of the property user.0 with Administrator,Administrator,21232F297A57A5A743894A0E4A801FC3. The resulting line must look like this
    user.0=Administrator,Administrator,21232F297A57A5A743894A0E4A801FC3 
    
  3. Restart the application server, and then you can log in to FusionReactor using the password: admin
  4. Remeber to set a new password immediately from the FusionReactor menu : Change Password option.

Note: If you are resetting the password for the FRAM instance then it's the framd (*nix) / FusionReactor AM Service (Windows) you should be restarting in step 3 above.

Issue Details

Type: Technote
Issue Number: FRS-155
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 10/Oct/13 10:51 AM
Affects Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1
Fixed Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 4.0.0
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, Flex Data Services, JBoss, JRun 4, LiveCycle Data Services, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, Solaris
Related Issues:

FRS-194: After upgrading a FusionReactor 2.0.4 to FusionReactor 3.0.x, I can no longer log in

FRS-321: Forgotten FusionReactor v5 password / Reset FusionReactor v5 password

[frs-224] Hotfix FR-1643: Standalone FR JDBC Wrapper Driver (for MySQL Connector/J etc.)


Hotfix 1643 for FusionReactor 3.0.1 – Description

This technote describes a fix for a condition under which you receive exceptions trying to wrap JDBC drivers which have been loaded by a classloader other than that which loaded the FusionReactor system filter. This occurs primarily on manual installs, or J2EE platforms not supported by the installer (e.g. Websphere), or if you are using third-party JDBC Driver jars.

Symptoms

Customers using FusionReactor in environments where the FusionReactor JDBC Driver Wrapper (and subsequent wrapped driver) is loaded by a different classloader than that used to load the FusionReactor system filter may observe one or more of the following issues:

  • The J2EE engine fails to find the FusionReactor JDBC Driver Wrapper (ClassNotFoundException).
  • The J2EE engine finds the FusionReactor JDBC Driver Wrapper but the wrapper cannot find an in-memory accessible instance of the FusionReactor system; in which case the wrapper will degrade to logging to the console.
  • The J2EE engine finds the FusionReactor JDBC Driver Wrapper, and the wrapper does locate an in-memory accessible instance of the FusionReactor system, but when attempting to send JDBC metrics to the system, encounters a class type mismatch (ClassCastException).

These symptoms occur mostly in situations where:

  • FusionReactor has been deployed manually, or
  • Customers are using third-party JDBC driver jars in JRun/ColdFusion, which previously had to have been copied to SERVER-INF/lib

Analysis

The problem is due to the way J2EE engines partition their classloaders. The FusionReactor system filter must be loaded either at the same level of a classloader hierarchy as JDBC Driver Wrapper or a higher level. If this invariant is not satisfied, the exceptions mentioned above may be raised.

In the past, we have encouraged customers using ColdFusion to transition to third-party drivers, where their location and position within the classloader hierarchy can be fully controlled, and to install the jars for these drivers alongside the installed fusionreactor.jar. However, certain customers who are using Macromedia (Merant/Data-Direct) drivers are unable to move these drivers because of a licensing restriction imposed by the supplier of these drivers. This problem usually occurs in environments where ColdFusion has been installed as an EAR/WAR deployment within a J2EE engine.

We have resolved this issue by re-writing the interface between the FusionReactor system filter and the FusionReactor JDBC Driver Wrapper to be independent of classloader. As long as the FusionReactor system filter has been loaded by the same (or higher) classloader as the FusionReactor JDBC Driver Wrapper and subsequent wrapped driver, there should be no issues concerning communication between the two.

Third-Party (OEM) JDBC Driver Jars

It is no longer necessary to move third-party driver JAR files (e.g. MySQL Connector/J, JTDS etc.) to the SERVER-INF/lib folder. After updating the system fusionreactor.jar with the attached version, the The fusionreactor-jdbc.jar file should be installed in ColdFusion8/lib alongside the mysql-connector-java-* file. The wrapped datasource should then verify correctly.

Resolution

Customers with FusionReactor 3.0.1 only should apply the attached Hotfix 1643. This consists of a new system fusionreactor.jar (with which you should replace your existing copy) and a new fusionreactor-jdbc.jar. This latter file should be placed in the same folder as your JDBC drivers.

Included Hotfixes

  • Hotfix 1623, described by technote FRS-216
  • Hotfix 1630, described by technote FRS-218
  • Hotfix 1635, described by technote FRS-219
  • Hotfix 1638, described by technote FRS-220
  • Hotfix 1640, described by technote FRS-222

Files

hotfix-FR-1643-FR-1640-1638-1635-1630-1623.FR-HEAD-1329.13132.zip

Taxonomy

After installation, FusionReactor's "About" page should identify itself as Revision: 3.0.2, Build: FR-HEAD.1329.13132.

Hotfix FR 1643 – obf. (Stream: trunk, build 1329, SVN 13132)

Issue Details

Type: Technote
Issue Number: FRS-224
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 16/May/12 4:52 PM
Affects Version: 3.0.1
Fixed Version: 3.0.1
Server: JBoss, Jetty, JRun 4, Railo, Resin, ServletExec, Tomcat, WebSphere, WebLogic
Platform:
Related Issues:

[frs-240] Standalone FR JDBC Wrapper Driver (for MySQL Connector/J etc.)


FusionReactor 4.5.0+…

Customers using FusionReactor 4.5.0 and above must not apply this technote. This issue has been resolved with the addition of a cp option to the JDBC driver wrapper. See Using the FusionReactor Driver Wrapper for more information.

Customers who have already applied FRS-240 to versions of FusionReactor prior to 4.5.0, and who plan to upgrade to 4.5.0 or greater should read FRS-296: "FusionReactor 4.5.0: Briefer for Split-Jar JDBC Wrapper Users".

Please Note…

This article applies to FusionReactor 3.5.x and 4.0.x. Customers with FusionReactor 3.0.1 should use Hotfix FR-1643.

Symptoms

Customers using FusionReactor in environments where the FusionReactor JDBC Driver Wrapper (and subsequent wrapped driver) is loaded by a different classloader than that used to load the FusionReactor system filter may observe one or more of the following issues:

  • The J2EE engine fails to find the FusionReactor JDBC Driver Wrapper (ClassNotFoundException).
  • The J2EE engine finds the FusionReactor JDBC Driver Wrapper but the wrapper cannot find an in-memory accessible instance of the FusionReactor system; in which case the wrapper will degrade to logging to the console.
  • The J2EE engine finds the FusionReactor JDBC Driver Wrapper, and the wrapper does locate an in-memory accessible instance of the FusionReactor system, but when attempting to send JDBC metrics to the system, encounters a class type mismatch (ClassCastException).
  • Customers attempting to verify their wrapped drivers with their J2EE engines (e.g. from within the ColdFusion Administrator) may receive the message Driver could not be found and loaded

These symptoms occur mostly in situations where:

  • FusionReactor has been deployed manually, or
  • Customers are using third-party JDBC driver jars in JRun/ColdFusion, which previously had to have been copied to SERVER-INF/lib

Analysis

The problem is due to the way J2EE engines partition their classloaders. The FusionReactor system filter must be loaded either at the same level of a classloader hierarchy as JDBC Driver Wrapper or a higher level. If this invariant is not satisfied, the exceptions mentioned above may be raised.

In the past, we have encouraged customers using ColdFusion to transition to third-party drivers, where their location and position within the classloader hierarchy can be fully controlled, and to install the jars for these drivers alongside the installed fusionreactor.jar. However, certain customers who are using Macromedia (Merant/Data-Direct) drivers are unable to move these drivers because of a licensing restriction imposed on Adobe by the supplier of these drivers. This problem usually occurs in environments where ColdFusion has been installed as an EAR/WAR deployment within a J2EE engine.

We have resolved this issue by re-writing the interface between the FusionReactor system filter and the FusionReactor JDBC Driver Wrapper to be independent of classloader. As long as the FusionReactor system filter has been loaded by the same (or higher) classloader as the FusionReactor JDBC Driver Wrapper and subsequent wrapped driver, there should be no issues concerning communication between the two.

Third-Party (OEM) JDBC Driver Jars

It is no longer necessary to move third-party driver JAR files (e.g. MySQL Connector/J, JTDS etc.) to the SERVER-INF/lib folder. After updating the system fusionreactor.jar using the procedure below, the The fusionreactor-jdbc.jar file should be installed in ColdFusion/lib alongside the third-party JDBC driver jar file. The wrapped datasource should then verify correctly.

Resolution

Customers with FusionReactor 3.5.0 or later only should perform the following procedure. This consists of installing a new system fusionreactor-core.jar (with which you should replace your existing copy of fusionreactor.jar) and a new fusionreactor-jdbc.jar. This latter file should be placed in the same folder as your JDBC drivers.

  1. Ensure the J2EE engine can locate, load and use the unwrapped data source.
  2. Locate the two new split jars within your /FusionReactor/etc/lib folder. These are named fusionreactor-core.jar and fusionreactor-jdbc.jar.
  3. Locate the existing installed fusionreactor.jar file, for example ColdFusion9/runtime/servers/coldfusion/SERVER-INF/lib/fusionreactor.jar
  4. Stop your J2EE (e.g. ColdFusion Application Server) engine.
  5. Make a copy of the installed .../SERVER-INF/lib/fusionreactor.jar and store this safely, in case a rollback is required.
  6. Remove the installed .../SERVER-INF/lib/fusionreactor.jar file and replace it with the fusionreactor-core.jar file, renaming it fusionreactor.jar after copying.
  7. Copy the fusionreactor-jdbc.jar to the same location as the jar containing your unwrapped JDBC driver.
  8. Restart the engine and attempt to verify the datasource.

Issue Details

Type: Technote
Issue Number: FRS-240
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 14/May/12 4:54 PM
Affects Version: 3.5
Fixed Version: 3.5, 4.0.0
Server: JBoss, Jetty, JRun 4, Railo, Resin, Tomcat, WebSphere, WebLogic
Platform:
Related Issues:

FRS-258: Updating a FusionReactor 3.x split-jar installation to 4.x

[frs-256] FusionReactor Enterprise Dashboard 1.5 Release Notes and Resolved Issues



FusionReactor Enterprise Dashboard Rev. 1.5


RELEASE NOTES

Status: 9-Aug-2011

Welcome to the FusionReactor Enterprise Dashboard!

We appreciate your feedback. Please use the web form or send mail to:

support@fusion-reactor.com

These Release Notes describe what is contained in this release, provide
late-breaking news, and list additional documentation for the software.

For additional information on FusionReactor, please visit our website at:

https://www.fusion-reactor.com

For known issues and further support, please see the following web pages:

https://www.fusion-reactor.com/fr/faq.cfm
https://www.fusion-reactor.com/fr/support.cfm

To Check for FusionReactor AIR Enterprise Dashboard updates, open the application and select the "Updates" tab from the login dialogue and click the "Check for updates" button. The status text will be updated showing the applications current update status: "Up to date" or "Update Available".
If an update is available, the "Update" button will be enabled. Clicking the update button will download and install the latest update, restarting the application with the new and installed update.

Note: The new AIR Application is built / compiled using a different version of both Flex and AIR. The installer / updater is not compatible between the two, therefore any old version of the AIR client should be manually removed / uninstalled before the new (latest version – 1.5) version is installed.

RESOLVED ISSUES

Key Issue Type Summary
FE33 Improvement Non responsive hyper links
FE30 Bug Install for AIR Dashboard didn't work
FE28 Improvement Bring the styling of FR AIR Dashboard in line with new look & feel of FR 4.0

Issue Details

Type: Technote
Issue Number: FRS-256
Components: FR Enterprise Dashboard Desktop Application
Environment:
Resolution: Fixed
Last Updated: 09/Aug/11 2:07 PM
Affects Version:
Fixed Version: 4.0.0
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, Flex Data Services, JBoss, Jetty, JRun 4, LiveCycle Data Services, Railo, ServletExec, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Windows Vista
Related Issues:

FRS-207: FusionReactor Enterprise Dashboard 1.1.5 Release Notes and Resolved Issues

[frs-254] Standalone Confluence JDBC wrapping (MS SQL SERVER)


Introduction

JDBC monitoring is a big part of FusionReactor but currently when you install FusionReactor, it does not monitor JDBC connections by default. The installer does not help you to create wrapped data sources, nor does it inform you that you have to configure a wrapped datasource to be able to see JDBC metric data. You must do this manually.

Walkthrough

Follow the confluence documentation here:

http://confluence.atlassian.com/display/DOC/Configuring+a+SQL+Server+Datasource+in+Apache+Tomcat

When you get to step 3 of the above documentation, please enter the wrapped url and new driver class instead (with your server details)

url="jdbc:fusionreactor:wrapper:{jdbc:jtds:sqlserver://int00d0:1433/jira};driver=net.sourceforge.jtds.jdbc.Driver"
driverClassName="com.intergral.fusionreactor.jdbc.Wrapper"

After you have done that, you must follow the steps below.

1. Ensure the J2EE engine can locate, load and use the unwrapped data source.
2. Locate the two new split jars within your /FusionReactor/etc/lib folder. These are named fusionreactor-core.jar and fusionreactor-jdbc.jar.
3. Locate the existing installed fusionreactor.jar file, for example confluence3.5.7/lib/fusionreactor.jar
4. Stop your J2EE (e.g. Tomcat Server) engine.
5. Make a copy of the installed ...confluence3.5.7/lib/fusionreactor.jar and store this safely, in case a rollback is required.
6. Remove the installed ...confluence3.5.7/lib/fusionreactor.jar file and replace it with the fusionreactor-core.jar file.
7. Copy the fusionreactor-jdbc.jar to the same location as the jar containing your unwrapped JDBC driver for example: C:/confluence3.5.7/confluence/WEB-INF/lib
8. Restart the engine and attempt to verify the datasource.

Now when starting Tomcat, you should see Fusion Reactor JDBC: Driver loaded if successful and a load of database queries output to console. The reason for this is Fusion Reactor is started later and doesn't catch the queries until it starts.

Issue Details

Type: Technote
Issue Number: FRS-254
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 09/Aug/11 1:01 PM
Affects Version:
Fixed Version: 4.0.0
Server: Tomcat
Platform: Windows XP
Related Issues:

[frs-230] FusionReactor 3.5.x Release Notes and Resolved Issues



FusionReactor Rev. 3.5.x


RELEASE NOTES

Status: 17-Feburary-2011

Welcome to FusionReactor!

We appreciate your feedback. Please use the web form or send mail to:

support@fusion-reactor.com

These Release Notes describe what is contained in this release, provide
late-breaking news, and list additional documentation for the software.

For additional information on FusionReactor, please visit our website at:

https://www.fusion-reactor.com

For known issues and further support, please see the following web pages:

https://www.fusion-reactor.com/fr/faq.cfm
https://www.fusion-reactor.com/fr/support.cfm

To check for FusionReactor updates use the update page

RESOLVED ISSUES 3.5.5

Key Issue Type Summary
FR2001 Bug License/activation data corrupted due to concurrent access of multiple FR processes

RESOLVED ISSUES 3.5.4

Key Issue Type Summary
FR1836 Bug NullPointerException from JDBC on Railo on getMetaData in some cases
FR1958 Bug In some cases small AMF content is not flushed

RESOLVED ISSUES 3.5.3

Key Issue Type Summary
FR1744 Bug XML content in Railo breaks with a SAX Parser error (org.xml.sax.SAXParseException)
FR1747 Bug FusionReactor runs thousands of samples after it dehibernates (use schedule and not scheduleAtFixedRate)

RESOLVED ISSUES 3.5.2

Key Issue Type Summary
FR1724 Improvement AMF processor should handle a Target in the same way as a serviceName and serviceMethodName

RESOLVED ISSUES 3.5.1

Key Issue Type Summary
FR1704 Bug The Request Details button on the Slow Requests page did not work in FusionReactor 3.5.0. Pressing the Request Details button now correctly calls the Request Details page for requests shown on the Slow Requests page.
FR1706 Bug After a FusionReactor trail period had expired, FusionReactor used too many files handles and did not free them. File handles are now freed correctly. This issue did NOT affect FusionReactor installations that had a valid license, only installations where the trial period had expired and no license was uploaded.

RESOLVED ISSUES 3.5.0

Key Issue Type Summary
FR1648 New Feature Support for ColdFusion 9
FR1693 New Feature Support for Railo 3.1
FR1669 New Feature Support for JBoss 5.1
FR1692 New Feature Support for Windows 2008 Server R2
FR1681 New Feature Support for Windows 7
FR1670 New Feature Support for Mac OS X 10.6 "Snow Leopard"
FR1682 Improvement Support for Flash Player 10c and Flash Player 9 update 5
FR1676 Improvement FusionReactor Setup/Installer and Updater Support for 64 bit Windows machines
FR1667 Improvement FusionReactor's Flash content appears always on top when embedded in HTML in AIR. Use WMODE to correct the problem.
FR1666 Improvement Update Installation Guide
FR1664 Improvement Enhance FRAPI Request Surrogates to include more detail (see JavaDoc)
FR1660 Improvement Update FREM Release Candidate to the 3.5 CORE
FR1658 Improvement New AMF Deserializer implementation / Support for AMF handling Externalizable Objects
FR1650 Improvement FusionReactor Licencing support for AIX on JVM 1.5
FR1691 Bug Installer should select the "coldfusion" J2EE webapp by default when installing FusionReactor into ColdFusion 9
FR1687 Bug Crash Protection Alert Emails are not sent from FusionReactor instances installed in ColdFusion 9
FR1684 Bug Sockets used by FusionReactor's web server can enter CLOSE_WAIT indefinitely when invalid HTTP requests are received
FR1680 Bug Requests sometimes show "null" instead of the server name in CF9
FR1665 Bug Enterprise Dashboard should be able to cope with server names longer than 24 characters
FR1659 Bug Uninstall should only remove FusionReactor files
FR1657 Bug HTTP Post without headers causes a Java NullPointerException; FusionReactors web server can stop working
FR1643 Bug FusionReactor JDBC Wrapper as standalone JAR. It should be possible to place the FR JDBC Wrapper JAR in the same folder as the wrapped JDBC driver to avoid having to move JDBC drivers
FR1638 Bug Deadlock (out-of-order lock acquisition) between FusionReactor's JDBC driver and Metric Probe
FR1630 Bug JDBC Metrics are not tracked when no owning request can be found (eg. in CFTHREAD JDBC request)
FR1622 Bug Illegal State Exception / Response Has Been Closed with upstream Java app on Servet Forward/Includes in JRun. FusionReactor must not wrap a forward/include request if the the source request was already wrapped by FusionReactor.
FR1694 Bug A Race condition in stream data metrics could cause a CrashProtection Request Limit Email Notification to fail under extreme load conditions

Issue Details

Type: Technote
Issue Number: FRS-230
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 08/Aug/11 11:18 AM
Affects Version:
Fixed Version: 3.5
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, Flex Data Services, JBoss, Jetty, JRun 4, LiveCycle Data Services, Railo, Resin, ServletExec, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64
Related Issues:

FRS-214: FusionReactor 3.0.1 Release Notes and Resolved Issues

FRS-251: FusionReactor 4.0.x Release Notes

[frs-198] Problems with installing or activating a license


FusionReactor License and Activation Issues

Version Check

We recommend that you first make sure that you have the most current version of FusionReactor installed as recent updates include license and activation fixes. You can download the most current version from the FusionReactor download page.

Problems and how to fix them

Typical problems

In the following section, we list the most often reported problems with the FusionReactor license and activation process as seen from the user's perspective. The typical causes of these problems are discussed subsequently, along with the steps necessary to solve them.

  1. Restarting the server expires a trial license or activation period immediately
  2. Attempting to activate a license with an expired activation period redirects to the login page (but the license was not activated)
  3. Installing a license shows an error page saying Can not upload license: null
  4. Installing a license silently fails (you get redirected to the login page but the license was not installed)
  5. Loss of license activation after reboot on some multi-server installations of FusionReactor 3.5.1

Typical causes

  1. Insufficient privileges of the server account when trying to write to the Java System Preferences Backing Store.
  2. A Java6 VM on Linux or Solaris that has no fix for SUN JVM bug 6519088
  3. Firefox browsers occasionally corrupting the license during the upload
  4. Trying to activate a license without a connection to the Internet (bug FR1409).

How to fix it

Insufficient privileges

The runtime user of the server on which FusionReactor is installed requires read/write access to the Java System Preferences Backing Store. Depending on the operating system, the location of this data store is different. On Windows the data is stored in the registry hive HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefs, the data belonging to FusionReactor is in HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor.
Page 14 of the FusionReactor Installation Guide provides you with instructions how to adjust the permissions of this store.
On Linux and Solaris the data is typically stored in the directory /etc/.java/.systemPrefs as a hierarchy of directories containing XML files. The data belonging to FusionReactor is in the directory /etc/.java/.systemPrefs/com/intergral/fusionreactor. To set the necessary permissions execute the following command as user root:

chmod -R 777 /etc/.java/.systemPrefs

Alternative locations of the System Preferences Backing Store

Some JVMs try to create the System Preferences Backing Store in the directory $JAVA_HOME/.systemPrefs as a fallback solution if the directory /etc/.java/.systemPrefs cannot be created where $JAVA_HOME denotes the directory where the JVM itself is located (e.g. /opt/coldfusionmx/runtime/jre ).

We strongly recommend you to use /etc/.java/.systemPrefs as the one and only location of the System Preferences Backing Store. In case there is already data from other applications in $JAVA_HOME/.systemPrefs you should move it to /etc/.java/.systemPrefs and delete $JAVA_HOME/.systemPrefs afterwards (after you have adjusted the permissions of /etc/.java/.systemPrefs properly).

Clear the System Preferences Backing Store

If you attempt to install a license and you get the error message mentioned before:

Can not upload license: null

or simply

null

then you should stop the application server, clear the content of the Java System Preferences Backingstore and restart the application server.

On a Windows machine run the registry editor (regedit.exe or regedt32.exe) and then delete the key

HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor

On a UNIX machine as user root delete the directory

/etc/.java/.systemPrefs/com/intergral/fusionreactor

If the permissions are configured correctly uploading a license and activating it will work properly afterwards.

On MacOS the System Preferences are stored as a set of *.plist files under the /Library/Preferences folder. Once the application server has stopped delete the file /Library/Preferences/com.intergral.fusionreactor.plist to clear all Preferences belonging to FusionReactor.

SUN Java 6 VM bug 6519088

This bug has been introduced with version 6 of the Linux and Solaris SUN Java VM and unfortunately has not been fixed even in the recently released version 6.0_05. We have a technote available at https://www.fusion-reactor.com/support/kb/FRS-168.cfm which provides you with detailed instruction how to apply a fix for this bug.

Bypassing problems with Firefox

If you upload a license with Firefox and nothing seems to happen (except that you have to login again) check the reactor-0.log file for the typical error message (see also https://www.fusion-reactor.com/support/kb/FRS-45.cfm) shown below

...
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when
decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_ae.b(DashoA12275)
at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
...

If multiple retries of uploading the license file again do not change this try to upload the license from a different browser and/or computer. If this does not help neither manually copy the license file to FusionReactor/license/license.lic and restart the server.

Making the manual activation process work

As mentioned in the overview of this document there is a hotfix available that fixes the bug FR1409 in the previous FusionReactor version 3.0.0 where a license can only be activated if the computer has a connection to the Internet. Download: fusionreactor-hotfix1409.zip. It comes as a ZIP file containing a new version of the FusionReactor Java library (fusionreactor.jar) together with instructions how to apply the fix. However, we recommend to upgrade to a newer version, which does not require this hotfix.

Issue Details

Type: Technote
Issue Number: FRS-198
Components: License + Activation
Environment:
Resolution: Fixed
Last Updated: 30/Jul/11 12:02 AM
Affects Version: 3.0, 3.0.1
Fixed Version: 3.0, 3.0.1, 3.5
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, Flex Data Services, JBoss, Jetty, JRun 4, LiveCycle Data Services, Railo, ServletExec, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista
Related Issues:

FRS-45: Why can’t I upload my license file (using Firefox)?

FRS-168: FusionReactor trial expires immediately on a Java6 VM running on Linux or Solaris

FRS-204: Safari web browser fails to upload license