Bug #7489
processing daemon common-logging misconfigured
0%
Description
the commons-logging.properties file appears misconfigured. It is missing the line:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
Hopefully, adding this line will allow all the apache commons logging calls to go to the log4j loggers.
Associated revisions
fixes #7489
commons-logging does not work with the configuration. adding in a new property.
fixes #7489
commons-logging does not work with the configuration. adding in a new property.
refs #7489
updating Trunk. commons-logging does not work with the configuration. adding in a new property.
refs #7489
updating Trunk. commons-logging does not work with the configuration. adding in a new property.
refs #7489
processing daemon commons-logging misconfigured. Adding in a classpath to the MANIFEST.MF generated by shade. Also excluding test-jars that were included from downstream projects. Specifically excluding log4j.properties file included by jena and d1-identity-manager
refs #7489
processing daemon commons-logging misconfigured. Adding in a classpath to the MANIFEST.MF generated by shade. Also excluding test-jars that were included from downstream projects. Specifically excluding log4j.properties file included by jena and d1-identity-manager
refs #7489
two different versions of BouncyCastle appear be be in the classpath now. Rollback classpath addition to see if adding '.' as classpath is the issue.
refs #7489
two different versions of BouncyCastle appear be be in the classpath now. Rollback classpath addition to see if adding '.' as classpath is the issue.
refs #7489
reverting changes to revision 16919
refs #7489
reverting changes to revision 16919
refs #7489
confirm that updating to next snapshot level does not cause the bouncycastle conflict
refs #7489
confirm that updating to next snapshot level does not cause the bouncycastle conflict
refs #7489
confirm that updating filters and adding classpath will not cause bouncycastle conflict
refs #7489
confirm that updating filters and adding classpath will not cause bouncycastle conflict
refs #7489
confirm that adding in d1_libclient_java test will cause bouncycastle conflict
refs #7489
confirm that adding in d1_libclient_java test will cause bouncycastle conflict
refs #7489
confirm that adding in d1_libclient_java test will cause bouncycastle conflict
refs #7489
confirm that adding in d1_libclient_java test will cause bouncycastle conflict
refs #7489
confirmed that excluding d1_libclient_java-test from the pom will cause bouncycastle conflict
refs #7489
confirmed that excluding d1_libclient_java-test from the pom will cause bouncycastle conflict
History
#1 Updated by Robert Waltz about 9 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Didn't work. We need to revise our logging strategy.
#2 Updated by Robert Waltz about 9 years ago
- Status changed from Closed to In Progress
- Target version changed from CCI-2.0.0 to CCI-2.1.0
- % Done changed from 100 to 30
#3 Updated by Robert Waltz about 9 years ago
- Target version changed from CCI-2.1.0 to CCI-2.0.2
#4 Updated by Robert Waltz about 9 years ago
- Target version changed from CCI-2.0.2 to CCI-2.1.0
- Status changed from In Progress to New
- % Done changed from 30 to 0
Initial work in a test executable showed that altering the classpath in the MANIFEST.MF allowed for apache commons-logging framework to discover the commons-logging.properties file contained within the d1-process-daemon shaded jar file. Formal testing of d1-processing daemon did not result in the same behaviour and commons-logging messages continued to default to STDOUT and STDERR.
Furthermore, changing the inclusion of testing jars from the compile scope to the test revealed a classloader issue with BouncyCastle. The issue is initially described in bug report #7535
#5 Updated by Robert Waltz almost 9 years ago
- Target version deleted (
CCI-2.1.0)
