While pursuing another matter, I found myself tinkering with the log4j configuration and startup, and once again found myself wondering why we bother with log.init.config and the code to support it.
Shouldn't we just drop a log4j.properties into each of the webapp.s, in addition to the one in [dspace]/config, and just let log4j find it in the normal way? Shouldn't bin/dspace just ensure that [dspace]/config is on the CLASSPATH and let log4j.properties be found normally? or stick that copy in [dspace]/lib instead. This would also allow us to have different logging configuration for commandline and each webapp. if that is convenient. Though likely the install process would just place identical copies, which could be customized after installation. We would want some support in build.xml to suppress overwriting of *all* of the log configurations, not just the one for dspace-api. Then we can drop some complexity in ConfigurationManager, which goes through a complicated dance to figure out whether logging is configured yet in order to know how to present each message. We should be able to simply assume that logging will be configured by the time we need for it to be, which is what log4j does when left to its own devices. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
