this is very probably a duplicate of bug 5826.

*** This bug has been marked as a duplicate of 5826 ***

Tried a separate log4j configuration file for gram auditing as
Tom suggested. It works fine (due to a configuration error of
mine it didn't work when I first tried it); there's a funny.
precondition though:
ws-gram uses the DB appender of log4j to put audit records in the
database, and log4j does not find the DB driver located in
$GLOBUS_LOCATION/lib. I assume this is because log4j is located
in $GLOBUS_LOCATION/lib/common. It worked after i copied the driver
jar over to $GLOBUS_LOCATION/lib/common.
This is probably not optimal, because we need DB driver jars in both
jar locations then (one for RFT in $GL/lib).

To illustrate what happens if the driver jar is not in
$GLOBUS_LOCATION/lib/common:

log4j:ERROR Failed to load driver
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:164)
        at org.apache.log4j.jdbc.JDBCAppender.setDriver(JDBCAppender.java:351)
        at
org.globus.exec.utils.audit.AuditDatabaseAppender.append(AuditDatabaseAppender.java:108)
        at
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
        at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
        at org.apache.log4j.Category.callAppenders(Category.java:206)
        at org.apache.log4j.Category.forcedLog(Category.java:391)
        at org.apache.log4j.Category.log(Category.java:856)
        at
org.apache.commons.logging.impl.Log4JLogger.debug(Log4JLogger.java:171)
        at
org.globus.exec.service.exec.processing.handler.helper.AuditLoggingHelper.logAuditRecord(AuditLoggingHelper.java:219)
        at
org.globus.exec.service.exec.processing.handler.StartStateHandler.process(StartStateHandler.java:61)
        at
org.globus.exec.service.exec.processing.handler.InternalStateHandler.processInternalState(InternalStateHandler.java:49)
        at
org.globus.exec.service.exec.processing.StateMachine.processInternalState(StateMachine.java:118)
        at
org.globus.exec.service.exec.processing.StateProcessingTask.run(StateProcessingTask.java:67)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

I don't think you would need it in both places.  If it's in lib/common, it
should get picked up by both classloaders automatically.  Unless RFT does
something funny like load it from a custom classloader or something.

works fine if the driver jars are only in $GL/lib/common

Creating their own log4j file that is loaded in the service classloader seems
to have solved the problem, so I'll mark this as fixed.

The database jars are deployed from database/java/common. Two services in the
toolkit depend on this, RFT and CAS. It is installed as a dependency pacakage,
that is it is not part of core and hence deployed into $G_L/lib.

It seems odd that log4j class path set to use from service class loader does
not pick up common classes - it needs to be investigated. But *if* drivers need
to be moved to lib/common directory, it needs to happen in the database/java
package and not in GRAM. The jars should definitely not be in both lib and
common/lib.

Changed ws-gram to not depend on the log4j database appender.
ws-gram's audit logger now uses a DataSource defined in JNDI.
Works fine so far, no classpath problems anymore.
Closing.