Great question, Mark. I'm actually not sure I even know the answer. A part of it may just have been trying to make it easier to ensure it's easier to turn on debugging everywhere in a single log4j.properties. It also may have been an attempt to have just one primary "dspace.log" which everything logs to (which would be backwards compatible with older, pre-Maven DSpace releases). Both of these are complete speculation on my part though. I have no idea why this came about to begin with.
Anyone else out there aware of the logic here? Your ideas here sound completely logical to me though, Mark. It seems like an improvement we definitely should consider. Thanks for continuing to point out possible "oddities" in the code, Mark! It's really helpful in making us rethink and possibly simplify areas of the codebase. - Tim On 2/12/2014 8:23 AM, Mark H. Wood wrote: > 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. > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
