Bug 5941 - class loading problem
: class loading problem
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: alpha
: Macintosh All
: P3 blocker
: 4.2.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-03-24 13:37 by
Modified: 2008-04-07 14:17 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-03-24 13:37:21
Just tried to test audit logging in ws-gram.
we currently do that using a database appender from log4j and define
the following in $GLOBUS_LOCATION/container-log4j.properties:

log4j.category.org.globus.exec.service.exec.processing.StateMachine.audit=DEBUG,
AUDIT
log4j.appender.AUDIT=org.globus.exec.utils.audit.AuditDatabaseAppender
log4j.appender.AUDIT.layout=org.apache.log4j.PatternLayout
log4j.additivity.org.globus.exec.service.exec.processing.StateMachine.audit=false

however, during container startup the class AuditDatabaseAppender is not
found although it exists:


[martin@osg-test1 lib]$ jar tf $GLOBUS_LOCATION/lib/globus_wsrf_gram_utils.jar 
META-INF/
META-INF/MANIFEST.MF
org/
org/globus/
org/globus/exec/
org/globus/exec/utils/
...
org/globus/exec/utils/audit/
org/globus/exec/utils/audit/AuditDatabaseAppender.class
...

Are there problems with class loading because we're having the
2 directories that contain jars: $GL/lib and $GL/lib/common?
------- Comment #1 From 2008-03-24 13:41:39 -------
this is very probably a duplicate of bug 5826.
------- Comment #2 From 2008-03-25 15:00:53 -------

*** This bug has been marked as a duplicate of 5826 ***
------- Comment #3 From 2008-04-03 20:56:38 -------
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).
------- Comment #4 From 2008-04-04 07:33:06 -------
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)
------- Comment #5 From 2008-04-04 08:02:12 -------
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.
------- Comment #6 From 2008-04-04 08:26:18 -------
works fine if the driver jars are only in $GL/lib/common
------- Comment #7 From 2008-04-04 08:27:33 -------
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.
------- Comment #8 From 2008-04-04 09:15:35 -------
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.
------- Comment #9 From 2008-04-07 14:17:17 -------
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.