SJSAS 9.1 u1, AJP/mod_jk and log4j troubles

I have been preparing for an update of Sun ONE Application Server 7 at work for some time now. A week ago I finally found a decent way to run Sun Java System Application Server 9.1 u1 on Solaris 9 under unprivileged account so that SJSAS could be reached on ports 80 and 443. The solution was to put Apache HTTP server in front of SJSAS using mod_jk and AJP (just like Tomcat often is installed). In the solution Apache will listen for the ports and deliver the requests to SJSAS using AJP. Gladly, Sun has provided instructions for this.

Unfortunately copying the three mentioned JARs (tomcat-ajp.jar, commons-logging.jar, and commons-modeler.jar) to the lib directory also had some unexpected side effects. After setting up AJP, we were unable to deploy WWW applications which used Commons-logging and log4j. This was because Commons-logging was now loaded by the common classloader and log4j was still loaded by the web classloader. Since log4j was loaded deeper in the classloader delegation hierarchy, Commons-logging was unable to see it. If Commons-logging was configured to use log4j (as we do), the web application failed to start because class org.apache.log4j.Category could not be located. You can read more about classloaders and Sun Application Server in the SJSAS manual.

The simplest solution would have been moving log4j to the SJSAS’s lib directory. This would have solved the problem with class visibility, but then all our applications would have used the same (common) version of the library (even if the application provided its own version of the library). This would have been a problem for us, since then it would not be possible for us to update the library for each application one by one. We would have to test all our applications when we needed a newer version of the library just for one of the applications. With out resources, this is simply not possible.

After some googling I come up with an idea of renaming the packages of Commons-logging and Commons-modeler. Sun has already been doing similar in SJSAS to prevent some class naming conflicts, since they use classes from Apache Commons and some other libraries. After modifying all the three JARs and replacing the previous versions I copied to the SJSAS lib directory, the problem was nicely solved.

I really wish that the support for AJP will be integrated to Glassfish V3 so that this trick will not be needed for it. On the other hand, by the time Glassfish V3 is released we will probably already have Solaris 10 on all of our servers. With Solaris 10 we can simply use ipf/ipnat to redirect the requests to the application server or we can use Solaris 10 privileges to allow unprivileged user to bind on privileged ports (<1024).

Submit a Comment

You must be logged in to post a comment.