On Jan 24, 2006, at 10:02 PM, Mark Womack wrote:
Curt, before I re-enable the FileWatchdog test case, can you try it on
your machine? I cleaned it up some, but looking at the code I'm not
sure how it was still printing the debug message. It explicitly checks
the level on the logger is INFO before printing any messages. But try
it now.
Test had been passing with my earlier modifications, now fails. The test
did not previously check for the level change, I added that a few days
ago when I addressed the issue which got both my local machine and Gump
working. See http://marc.theaimsgroup.com/?
l=log4j-dev&m=113805291616535&w=2.
I had introduced adding an intentional delay before rewriting the new
configuration file. The resolution in the last modification time varies
between platforms and file systems. Without the delay, it is possible
that the last modification time does not "appear" to change since the
last modification times are identical. The documentation for
File.setLastModified() indicates that you can not assume resolution less
than a second on the filesystem. I think it is more reliable just to
wait since writing and setting the last modified time could result in the
new configuration file being processed twice (once on the write and once
on the change of modification time).
Erg. So, it was working fine and now I have broken it? Guess I'll revert
it back then.
I am still planning to do the next 1.3 build (alpha 8) tomorrow evening.
If you have any changes you want to make it in, please have them checked
into svn by 7pm US pacific time.
Unless I get an objection, I'll put the NTEventLogAppender back in
tomorrow. The build will be like the MinGW build for the
NTEventLogAppender.dll in the log4j 1.2 branch. To build the
NTEventLogAppender.dll, you will need:
a) Have MinGW (http://mingw.sourceforge.net) installed and on the path.
Must be ahead of Cygwin, use gcc --dumpversion to make sure.
b) Have the Microsoft Message Compiler from the Microsoft Platform SDK on
the path (see http://msdn.microsoft.com/platformsdk)
I'll have to get all that set up on my machine.
Do we want to add a log4j-all-${version}.jar that would contain all the
class files which could be used as a replacement for log4j-1.2.x.jar?
+1
We also need to update the HISTORY.txt. Looking at the state of the
documentation for 1.3, there are links to Ceki's "Preparing for 1.3"
document on his website. I don't think it is as valid as it used to be at
this point. We need to create our own that is part of our docs. I'm not
suggesting we delay the build, but we need to address it soon.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
