cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: Configuration Problem?
Date Fri, 16 Apr 2004 14:36:04 GMT
Would the ParanoidCocoonServlet solve this problem?

-----Original Message-----
From: [] 
Sent: Thursday, April 15, 2004 5:56 PM
Subject: Configuration Problem?

      Following is an overview of a problem we are having with the
implementation of our first delivery of an application developed by a third
party. We are using Websphere 4 and Cocoon 2.1.


The PRDesktop is a J2EE enterprise application consisting of a single web
module. It has been developed by an exdternal party and is intended for
deployment to the clustered Websphere Server environment. The application
is intended to service users on the intranet.

Application Architecture

The PRDesktop is a J2EE enterprise application consisting of a single web
module. It utilises the Apache Cocoon framework.

Problem description

The application can be tested successfully under Websphere Studio
Application Developer running on the desktop. However, when deployed to the
AIX application the server  the application fails to deploy with a
LogKit-related exception (see fig 1).

The failure occurs during the cocoon servlet init() method, a fundamental
part of application startup.

Problem Analysis

Investigations suggest that the presence of Avalon, Excalibur and LogKit
JAR files in the directory /usr/WebSphere/AppServer/lib/app (see fig 2) are
causing interference during class loading. The JARs in question contain
older version of classes contained in the deployment EAR (WEB-INF/lib).

This interference is evident when examining the exception stack trace (fig
2) and the associated  Excalibur source code. It is apparent that the
classes from the package org.apache.avalon.excalibur.logger
Are being loaded,  not from the application EAR, but from the <was>/lib/app

These classes (DefaultLogKitManager and DefaultLogTargetFactoryManager)
are older versions than those in the application EAR. The latter class get
a ClassNotFoundException when a class only available in the application EAR
(org.apache.cocoon.util.log.CocoonTargetFactory)is not visible to the class
loader at the <was>/lib/app level.

Apparently these older JARs are present in the <was>/lib/app directory to
support serialisation of JAVA objects for the ARF (Architecture Reference
Framework). They have been there for some time. The choice of location is

The following components were replaced with more recent versions extracted
from the Cocoon installation of PR Desktop:
|                                    |                                    |
|Avalon.jar                          |avalon-framework-4.1.4.jar          |
|logkit.jar                          |logkit-1.2.jar                      |
|Excalibur.jar                       |excalibur-i18n-1.0.jar              |
|                                    |excalibur-logger-1.0.1.jar          |

Surprisingly, the Cocoon servlet actually completed its initialization as
evidence by the following WebSphere log entry:

[4/15/04 8:36:19:095 EST] 5c014676 WebGroup      I SRVE0091I: [Servlet
LOG]: Cocoon: init
[4/15/04 8:36:30:608 EST] 5c014676 SystemOut     U Using getRealPath:

As mentioned the ARF LogListener has an important role of processing
messages. However, this catastophically failed with the new Avalon
libraries - specifically:
[4/15/04 8:19:08:812 EST] 7c85044d WebGroup      X Servlet
Failed to load servlet: java.lang.IllegalArgumentException: logger is null

The way forward

We would like to remove the JARs from <was>/lib/app,  however, moving the
JARs is a problem because of potential impact on existing production

Perhaps the class loader can be constrained to look in the EAR/WAR before
asking the parent WebSphere class loader to locate unfound classes?


Steve Ferrington

NOTICE - This message is intended only for the use of the 
addressee named above and may contain privileged and 
confidential information.  If you are not the intended recipient
of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it.  If you 
received this message in error please notify HIC immediately.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of HIC.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message