logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ufuk Kayserilioglu <gro...@paralaus.com>
Subject Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Date Wed, 27 Feb 2008 10:01:29 GMT
Curt Arnold wrote:
> Based on the feedback from the mailing lists, as release manager, I'm 
> recalling log4cxx-0.10.0-rc2 from consideration and expect to prepare 
> another release candidate in a few days.  Additional feedback on the 
> release candidate is still desired.
>
> This is a quick list of items that should be resolved in the next RC:
>
> Extra semi-colons on expansion of LOG4CXX_PTR_DEF causes compile error 
> on Sun Studio 8  (fixed in SVN)
> Broken include directories for APR and APR-Util in Visual Studio 
> projects (LOGCXX-247).
> XCode project file assumes Mac OS/X 10.5.
> Release should include configure and supporting files produced by 
> autogen.sh.
>
> I will review the new comments on LOGCXX-231.  The most recent 
> comments looked a new bug unrelated to the original and didn't have 
> enough information to diagnose.
>
> I'd like to consider adding an DllRegisterServer and 
> DllUnregisterServer entry point for NTEventLogAppender to register the 
> message resource for the Event Log viewer.  Currently the resources 
> are attempted to be added on a logging request if they keys are not 
> present.  However, that can be a privileged operation that should be 
> done at install time which the user may have agreed to elevated 
> privileges.  Makes sense for a log4cxx.dll, but don't think it makes 
> sense during a static library.  Probably have static members in 
> NTEventLogAppender for the registration and unregistration and have 
> the standard entry points just delegate to those methods.

Thank you for all your efforts in trying to get a 0.10 release out of
the door; it was much needed.

There is, however, still one issue that we see as very critical on
Windows platforms that results in an application hang because of a
config reload and has been reported twice to the Dev list and as
LOGCXX-246 <https://issues.apache.org/jira/browse/LOGCXX-246>. The
problem stems from a wrong assumption about Thread::stop() method call
and the fix, as we have gone about doing it, is very simple to implement.

Could you please consider it for the next RC as well?

Many thanks,

Ufuk Kayserilioglu



Mime
View raw message