Hello,I think this occurred when there were changes to support log4j xml configuration files... the behavior became very hardcoded... And I undid it in the codebase for 1.5.x as one of my first commits as a dspace developer. I was very frustrated with how DSpace was controlling log4j configuration as it should really be handled by the containing application and not the way it is hardcoded into DSpace. In dspace 1.5.x you are able to start your Handle service with the following configuration, you will find that all logging configuration will be left up to that configured by the container..
-Ddspace.log.init.disable=true
So now the handle server starts up with
nohup $BINDIR/dsrun -Ddspace.log.init.disable=true - Dlog4j.configuration=log4j-handle-plugin.properties net.handle.server.Main $handledir </dev/null >> $logdir/handle- server.log 2>&1 &
Stopping DSpace from controlling logging.I think its horrible that we use log4j and the dspace.log to generate administrative/usage statistics, its a messy cesspool and will always be brittle like this. It needs changing and this is something that the GSoC Statistics project addressed somewhat last year.
----I've attached a jar that contains my changes to ConfigurationManager if you place into your [dspace.dir]/lib directory, then it should allow you to set your log4j settings for the start-handle-server script above. Please be aware this is at your own risk, but I've used this approach in the past.
You need to do the following.
1.) add one of the following line to your dspace.cfg
log.init.config = ${dspace.dir}/config/log4j.properties
log.init.config = ${dspace.dir}/config/log4j.xml
2.) place the jar in your lib directory
3.) change any startup scripts to use "-Ddspace.log.init.disable=true
-Dlog4j.configuration=<your file in ${dspace.dir}/config>"
likewise you can also designate it as an absolute url "file:///some/ path/to/log4j.properties"
Cheers, Mark
00-dspace-configuration.jar
Description: application/java-archive
I'm including the source so you can see exactly what is changing...
try { /** Initialize Logging once ConfigurationManager is initialized.** This is selection from a property in dspace.cfg, if the property * is absent then nothing will be configured and the application* will use the defaults provided by log4j. * * Property format is: * * log.init.config = ${dspace.dir}/config/log4j.properties * or * log.init.config = ${dspace.dir}/config/log4j.xml * * See default log4j initialization documentation here: * http://logging.apache.org/log4j/docs/manual.html * * If there is a problem with the file referred to in * "log.configuration" it needs to be sent to System.err * so do not instantiate another Logging configuration. * */String dsLogConfiguration = ConfigurationManager.getProperty("log.init.config");if (dsLogConfiguration == null || System.getProperty ("dspace.log.init.disable") != null){ /** Do nothing if log config not set in dspace.cfg or "dspace.log.init.disable" * system property set. Leave it upto log4j to properly init its logging* via classpath or system properties. */info("Using default log4j provided log configuration," + "if uninitended, check your dspace.cfg for (log.init.config)");} else {info("Using dspace provided log configuration (log.init.config)");File logConfigFile = new File(dsLogConfiguration); if(logConfigFile.exists()) { info("Loading: " + dsLogConfiguration);OptionConverter.selectAndConfigure (logConfigFile.toURL(), null, org.apache.log4j.LogManager.getLoggerRepository());} else {info("File does not exist: " + dsLogConfiguration);} } } catch (MalformedURLException e) {fatal("Can't load dspace provided log4j configuration", e); throw new RuntimeException("Cannot load dspace provided log4j configuration",e);}
On Mar 20, 2008, at 7:48 AM, Kyle Kaliebe wrote:
Shane,We use Tomcat on Red Hat Linux for our main installation so I do not think the application server is the cause here.Kyle Kaliebe Systems Developer/Engineer Knowledge Bank University Libraries Ohio State University [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:38 To: Kyle Kaliebe Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] inconsistent log outputWe are having the exact same problem here, and I have been unable to diagnose it, even after consulting with one of the DSpace committers for a few hours. I am of the thought that it may be related to our use of mac servers, and using JBoss instead of Tomcat on our production server. Right now there is a discrepancy between our test server, which uses Tomcat, and our production server. The test server logs work just fine, even on 1.4.2. When 1.5 final is released, we will be upgrading and doing whatever needs to be done to make Tomcat function properly on our production server, and are hopeful this will solve the issue. However, if it doesn't, I'm going to be even more frustrated! :)If you determine what's going on please let us know! Shane Beers Digital Repository Services Librarian George Mason University [EMAIL PROTECTED] http://mars.gmu.edu 703-993-3742 On Mar 20, 2008, at 10:05 AM, Kyle Kaliebe wrote: Dear Dspace tech list,< op: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; ">We are having issues with the way our dspace.log file is being written. We believe this behavior began with our upgrade to version 1.4.2. The main issue is that our handle server is writing its logs to dspace.log in lieu of handle-plugin.log. This is causing issues with functionalities that are dependent on dspace.log (things like administrator statistics). We have ensured that our handle server is configured to write to handle-plugin.log. Whenever we restart our handle server, it writes logs to handle-plugin.log for a few seconds, then switches to dspace.log. In addition, the expected input to dspace.log is sometimes blocked altogether. We have made sure that all relevant files and processes are being run as the installing linux account.Does anyone have any ideas on what we might try to resolve this? Thanks and happy vernal equinox!---------------------------------------------------------------------- ---This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
