Project

General

Profile

Bug #7489

processing daemon common-logging misconfigured

Added by Robert Waltz over 8 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
Robert Waltz
Category:
d1_cn_process_daemon
Target version:
-
Start date:
2015-11-16
Due date:
% Done:

0%

Story Points:
Sprint:

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

Revision 16908
Added by Robert Waltz over 8 years ago

fixes #7489

commons-logging does not work with the configuration. adding in a new property.

Revision 16908
Added by Robert Waltz over 8 years ago

fixes #7489

commons-logging does not work with the configuration. adding in a new property.

Revision 16918
Added by Robert Waltz over 8 years ago

refs #7489

updating Trunk. commons-logging does not work with the configuration. adding in a new property.

Revision 16918
Added by Robert Waltz over 8 years ago

refs #7489

updating Trunk. commons-logging does not work with the configuration. adding in a new property.

Revision 17148
Added by Robert Waltz over 8 years ago

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

Revision 17148
Added by Robert Waltz over 8 years ago

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

Revision 17160
Added by Robert Waltz over 8 years ago

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.

Revision 17160
Added by Robert Waltz over 8 years ago

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.

Revision 17162
Added by Robert Waltz over 8 years ago

refs #7489

reverting changes to revision 16919

Revision 17162
Added by Robert Waltz over 8 years ago

refs #7489

reverting changes to revision 16919

Revision 17164
Added by Robert Waltz over 8 years ago

refs #7489

confirm that updating to next snapshot level does not cause the bouncycastle conflict

Revision 17164
Added by Robert Waltz over 8 years ago

refs #7489

confirm that updating to next snapshot level does not cause the bouncycastle conflict

Revision 17166
Added by Robert Waltz over 8 years ago

refs #7489

confirm that updating filters and adding classpath will not cause bouncycastle conflict

Revision 17166
Added by Robert Waltz over 8 years ago

refs #7489

confirm that updating filters and adding classpath will not cause bouncycastle conflict

Revision 17167
Added by Robert Waltz over 8 years ago

refs #7489

confirm that adding in d1_libclient_java test will cause bouncycastle conflict

Revision 17167
Added by Robert Waltz over 8 years ago

refs #7489

confirm that adding in d1_libclient_java test will cause bouncycastle conflict

Revision 17168
Added by Robert Waltz over 8 years ago

refs #7489

confirm that adding in d1_libclient_java test will cause bouncycastle conflict

Revision 17168
Added by Robert Waltz over 8 years ago

refs #7489

confirm that adding in d1_libclient_java test will cause bouncycastle conflict

Revision 17169
Added by Robert Waltz over 8 years ago

refs #7489

confirmed that excluding d1_libclient_java-test from the pom will cause bouncycastle conflict

Revision 17169
Added by Robert Waltz over 8 years ago

refs #7489

confirmed that excluding d1_libclient_java-test from the pom will cause bouncycastle conflict

History

#1 Updated by Robert Waltz over 8 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 over 8 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 over 8 years ago

  • Target version changed from CCI-2.1.0 to CCI-2.0.2

#4 Updated by Robert Waltz over 8 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 about 8 years ago

  • Target version deleted (CCI-2.1.0)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)