JRun 4 Updater 6 Known Issues

JRun 4 Updater 6 for Windows, UNIX, Linux, and MacOSX

This document describes the known issues in JRun 4 Updater 6. For a list of known issues with prior releases of JRun 4, see JRun 4 Updater 5 known issues (build 92909).

• 57037 - Solaris installations fail reporting "ERROR" in the preinstallation summary "Available space" section. This occurs when there is approximately 6 GB of free space or more on the partition. Systems with less than 6 GB free space work correctly.
• 56942 - RedHat AS 2.1. Updater hangs when it unpacks files if the IBM JDK 1.3.1 is the default JDK.
• 59348 - RedHat Linux AS 3.0. JSPs throw error. Jikes needs a newer libstdc++ than currently in /usr/lib.
  
  500 Translator.CompilationFailedExceptionCompiler errors:/opt/jrun4/bin/jikesw: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
  
  
  
  /usr/lib/libstdc++.so.5.0.3 is the version installed in this case
  
  
  
  To find the version of libstc++
  
  
  
  rpm -ql libstdc++ /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.3
• 61050 - Installation fails on Solaris 8 with the message:
  
  
  
  Installer User Interface Mode Not Supported Unable to load and to prepare the installer in console or silent mode. This is an issue with the 1.4.2 JDK. The issue does not occur with JDK 1.5.
  
  
  
  Possible solutions:
  • In order to use the 1.4.2 JDK, you must first download the Solaris 8 OS patch for the JDK (using the link provided below) and install it before running the Updater 6 installer.
    
    Solaris 8 OS patch for 1.4.2
    
    
    
    -or-
    
    
  • Use the 1.5 JDK.
• 61142 - The installer fails on RedHat AS 4.0 and ES in the default configuration. Warning: -Xmx50331648 not understood. Ignoring. Warning: -Xms50331648 not understood. Ignoring. Unable to locate the application's 'main' class. The class 'com.zerog.ia.installer.Main' must be public and have a 'public static void main(String[])' method. (LAX) This occurs because the installer doesn't work with the default Redhat 4.0 GCC JDK found in /usr/bin.
  
  
  
  Even if a Sun JDK is installed, installs will still fail due to the symbolic link in /usr/bin to the GCC JDK. Do the following to resolve the issue:
  1. Install a Sun JDK 1.4.2.
  2. cd /usr/bin
  3. rm java (remove symbolic link to GCC JDK)
  4. ln -s /opt/j2sdk1.4.2/bin/java java

• 54101 - When JRun is installed in a directory with a space, the Connector Installer wizard will not detect running JRun servers. The JMC also doesn't show the server status as running. See TechNote 4c7d1c1 for instructions on how to resolve this issue.
• 56180 - JRun launcher crashes when using IBM JDK 1.4.1 and generates the following message: "Could not create the Java virtual machine". No workaround is available. This issue is seen only on RedHat AS 2.1 and with multi-CPU machines. Exporting LD_ASSUME_KERNEL=2.2.5 helps but launcher can still crash.
• 60268 - On RedHat AS 4.0, which comes with Bundled Apache 2.0.52, after configuring the connectors, the Apache server does not restart.
  
  
  
  Workaround 1: On RedHat AS 4.0, when using Apache web server, Apache may throw the error "failed to map segment from shared object: Permission denied" with the JRun connector. This is an issue of Linux Security settings. The solution is Disabling SELunix protection for HTTPD service (System Settings > Security Level)
  
  
  
  Workaround 2: Copy the connector fromjrun_home/lib/wsconfig/1/mod_jrun20.so into Apaches default modules directory (usr/lib/httpd/modules or apache home directory/modules). Also modify the path of mod_jrun20.so in httpd.conf (typically located in /etc/httpd/conf or apache home directory/lib).
• 60294 - 404 'Page Not Found' thrown when requesting a resource (/index.jsp) with the NSAPI connector configured with Sun One 6.1 SP2 on Sun Solaris9. No connector configuration errors are thrown. Disable the JSP/Servlet engine of Sun One 6.1 SP2 to make it work with JRun.
• 60794 - ProxyRetryInterval is not set in the SunOne configuration during installation.
  
  
  
  Add this entry manually in magnus.conf, along with the other JRun connector settings. The default value for this is 600 seconds. Init fn="load-modules" shlib="C:/JRun4/Updater6/lib/wsconfig/1/jrun_nsapi.dll" funcs="jruninit,jrunfilter,jrunservice" Init fn="jruninit" serverstore="C:/JRun4/Updater6/lib/wsconfig/1/jrunserver.store" bootstrap="127.0.0.1:51000" verbose="false" apialloc="false" ignoresuffixmap="false" connecttimeout="15" recvtimeout="300" sendtimeout="15"proxyretryinterval="600"
• 60922 - SuSE Linux needs to be configured in ipv4 mode in order for the web server connector installer to work properly. For the 9.3 version, this configuration is found in /etc/modprobe.conf. The connector installer cannot detect the running JRun server in ipV6 mode.
  
  
  
  The installer does a library compatibility check before configuring the Apache 2.0 connector for SuSE. Occasionally, SuSE configurations have compatibility libraries that don't match what the Apache connectors were compiled with and the installed connector will hang and not serve pages. In these cases, the connector needs to be compiled manually.
• 60947 - java.io.InvalidClassException thrown while running wsconfig using JDK 1.5 if the JRun server uses JDK 1.4. wsconfig shows "exception occured trying to get an MBean". Edit wsconfig_jvm.config and point java.home= to JDK 1.4.
• 61210 - On Windows 2003/IIS 6, the response is truncated if the page contains a redirect (cflocation in ColdFusion MX). This can happen intermittently. A hot fix for this issue is available in TechNote 5c9389c8.

• 60589 - When transaction domain is not DefaultDomain, the transaction is not rolled back even though the transaction times out.
  
  
  
  In jrun-resources.xml, under the <data-source> section, rename the <transaction-domain> tag to <tx-domain> tag.
  
  
  
  For example: <data-source> ...<transaction-domain>MyDomain</transaction-domain> ...</data-source>
  
  Should be converted to: <data-source> ...<tx-domain>MyDomain</tx-domain> ...</data-source>
• 60318 - When <load-system-classes-first> is false, if log4j loggers are initialized in static block of filter class, the log4j is not initialized for the whole application.
  
  
  
  log4j1.2.9 uses the following order to look for its configuration when the log4j.configuration system property is undefined:
  1. Load the log4j.xml using the thread context classloader.
  2. Load log4j.xml using the class loader that loaded the "Logger" class.
  3. Load lo4j.properties using the thread context classloader.
  4. Load log4j.properties using the class loader that loaded the "Logger" class.
  
  
  The thread context classloader gets the first chance to load the config properties and not the classloader that loaded the "Logger" class.
  
  
  
  Load-system-classes first FALSE scenario:
  
  When using log4j with filters that are loaded by JRun at deployment time, the thread context classloader is the server classloader . However, the JRun FilterManager uses the Web Application classloader to load the "Logger" class if log4j.jar is placed in WEB-INF/lib. This can cause log4j to behave in an unspecified way if the log4j version shipped with JRun is different from the one supplied with the webapp because the properties file being used might not be compatible with the log4j version being used. [Currently log4j.properties is being picked from axis.jar].
  
  
  
  Load-system-classes-first TRUE scenario:
  
  Both the "Logger" class and the log4j.properties configuration file are loaded by the server class loader thereby working fine. However, this scenario doesnt allow using newer versions of log4j.
  
  
  
  Solution:
  1. When using load-system-classes-first false:
     
     Use log4j.xml instead of the log4j.properties since JRun doesn't ship with any log4j.xml. Hence the server classloader will always fail to find log4j.xml and the webapp classloader can load it from the web app. Since log4j.xml is searched for before searching for log4j.properties, the configuration files shipped with server would be ignored.
  2. Another solution is to initialize log4j in the preferred way of initialization as specified by the log4j documentation. public class Log4jInit extends HttpServlet { public void init() { String prefix = getServletContext().getRealPath("/"); String file = getInitParameter("log4j-init-file"); // if the log4j-init-file is not set, then no point in trying if(file != null) { PropertyConfigurator.configure(prefix+file); } } public void doGet(HttpServletRequest req, HttpServletResponse res) { } } This approach however might prevent log4j from behaving properly when used in webcomponents that are initialized by JRun at deployment time.
  3. Yet another solution is to set the log4j.configuration system property pointing to the log4j.properties intended to be used. This, however, prevents using different configurations for different web applications.