You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2008/02/27 08:55:27 UTC
[VOTE][RECALL] log4cxx 0.10.0-rc2
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.
Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Posted by Ufuk Kayserilioglu <gr...@paralaus.com>.
Curt Arnold wrote:
>
> On Feb 27, 2008, at 4:01 AM, Ufuk Kayserilioglu wrote:
>> 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
>>
>>
>
>
> Sorry to leave it off the list. I was writing at the end of a long
> day. I did see the bug report minutes after posting RC2. I haven't
> had a chance to look at the issue.
>
> My process would be to check:
>
> How similar is the log4j and log4cxx implementations?
> If they are similar is it a flaw in both implementations, or is it a
> flaw in the emulation of java.lang.Thread?
> How to write a test case that would identify the issue?
>
> I won't be able to look at it for a few more days, so if anyone wants
> to take a shot at answering those questions, add them as comments to
> the bug report.
I have just answered these questions in a comment to the bug report. You
can access it here
<https://issues.apache.org/jira/browse/LOGCXX-246?focusedCommentId=12573657#action_12573657>.
Best regards,
Ufuk Kayserilioglu
Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Posted by Curt Arnold <ca...@apache.org>.
On Feb 27, 2008, at 4:01 AM, Ufuk Kayserilioglu wrote:
> 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
>
>
Sorry to leave it off the list. I was writing at the end of a long
day. I did see the bug report minutes after posting RC2. I haven't
had a chance to look at the issue.
My process would be to check:
How similar is the log4j and log4cxx implementations?
If they are similar is it a flaw in both implementations, or is it a
flaw in the emulation of java.lang.Thread?
How to write a test case that would identify the issue?
I won't be able to look at it for a few more days, so if anyone wants
to take a shot at answering those questions, add them as comments to
the bug report.
Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Posted by Ufuk Kayserilioglu <gr...@paralaus.com>.
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
Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Posted by re...@rubixinfotech.com.
Curt
There were two more issues with patches that I had provided for the Sun One
Studio (related to facets) against LOG4CXX-62..
Here is a copy of the comments:
Additional fixes needed for Solaris + Sun One Studio... since the STL
implementation has issues returning the template param for has_facet
and use_facet:
diff -r apache-log4cxx-0.10.0/src/main/cpp/simpledateformat.cpp
/export/home/renny/apache-log4cxx-0.10.0
/src/main/cpp/simpledateformat.cpp
45a46
> #ifndef _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE
47a49,52
> #else
> #define HAS_FACET(locale, type) std::has_facet(locale,(type *)0)
> #define USE_FACET(locale, type) std::use_facet(locale,(type *)0)
> #endif
diff -r apache-log4cxx-0.10.0
/src/test/cpp/helpers/datetimedateformattestcase.cpp
/export/home/renny/apache-log4cxx-0.10.0/src/test/cpp/helpers/dat
etimedateformattestcase.cpp
187a188
> #ifndef _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE
189a191,194
> #else
> std::use_facet(locale,(std::time_put<logchar> *)0)
> .put(buffer, buffer, buffer.fill(), &date, fmt.c_str(), fmt.c_str()
+ fmt.length());
> #endif
Renny Koshy
President & CEO
--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com
Curt Arnold
<carnold@apache.o
rg> To
Log4CXX Dev
02/27/2008 02:55 <lo...@logging.apache.org>
AM cc
Log4CXX User
<lo...@logging.apache.org>,
Please respond to Logging General
"Log4CXX Dev" <ge...@logging.apache.org>
<log4cxx-dev@logg Subject
ing.apache.org> [VOTE][RECALL] log4cxx 0.10.0-rc2
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.
Re: [VOTE][RECALL] log4cxx 0.10.0-rc2
Posted by re...@rubixinfotech.com.
Curt
There were two more issues with patches that I had provided for the Sun One
Studio (related to facets) against LOG4CXX-62..
Here is a copy of the comments:
Additional fixes needed for Solaris + Sun One Studio... since the STL
implementation has issues returning the template param for has_facet
and use_facet:
diff -r apache-log4cxx-0.10.0/src/main/cpp/simpledateformat.cpp
/export/home/renny/apache-log4cxx-0.10.0
/src/main/cpp/simpledateformat.cpp
45a46
> #ifndef _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE
47a49,52
> #else
> #define HAS_FACET(locale, type) std::has_facet(locale,(type *)0)
> #define USE_FACET(locale, type) std::use_facet(locale,(type *)0)
> #endif
diff -r apache-log4cxx-0.10.0
/src/test/cpp/helpers/datetimedateformattestcase.cpp
/export/home/renny/apache-log4cxx-0.10.0/src/test/cpp/helpers/dat
etimedateformattestcase.cpp
187a188
> #ifndef _RWSTD_NO_TEMPLATE_ON_RETURN_TYPE
189a191,194
> #else
> std::use_facet(locale,(std::time_put<logchar> *)0)
> .put(buffer, buffer, buffer.fill(), &date, fmt.c_str(), fmt.c_str()
+ fmt.length());
> #endif
Renny Koshy
President & CEO
--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com
Curt Arnold
<carnold@apache.o
rg> To
Log4CXX Dev
02/27/2008 02:55 <lo...@logging.apache.org>
AM cc
Log4CXX User
<lo...@logging.apache.org>,
Please respond to Logging General
"Log4CXX Dev" <ge...@logging.apache.org>
<log4cxx-dev@logg Subject
ing.apache.org> [VOTE][RECALL] log4cxx 0.10.0-rc2
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.