log4cplus-devel

[Log4cplus-devel] log4cplus 1.0.4-RC8 released

[Václav H. <v.h...@sh...>]

log4cplus 1.0.4-RC8 has been released. The most interesting changes are
portability fixes. log4cplus now builds and runs on OpenSolaris compiled
using Sun C++ compiler. It has also been compiled and tested on
OpenBSD/AMD64 4.7.

-- 
wilx


Version 1.0.4-RC8

  - Always handle %s time format specifier (seconds since epoch) in
    log4cplus. Detect and use clock_gettime() when available.
  - Fixed compilation on OpenSolaris with Sun C++.
  - Fixed compilation on OpenBSD.
  - Fixed use of operator delete/delete[] in FileAppender (Patch
    #3005234).
  - Updated config.guess and config.sub to latest Git repository
    versions.
  - Added BufferSize property to FileAppender to allow control of the
    appender's output buffer.
  - Removed -fkeep-inline-functions from GCC flags for non-debugging
    build.

Version 1.0.4-RC7

  - Fixed thread safety issues with gethostbyname() by using
    getaddrinfo() instead, where available.
  - Fixed bug #2965390 - Minor internal debugging output issue.
  - Added --enable-warnings (--disable-warnings) switches to the
    configure script.
  - Added ReopenDelay property to FileAppender, allowing the appender
    to reopen output stream after write failure. (Patch #2971315)

Version 1.0.4-RC6

  - Fixed bug #2945335 - MinGW/MSYS build problems. For Windows builds
    the source now defaults to static library/empty LOG4CPLUS_EXPORT
    macro.
  - Fixed a security problem in SyslogAppender.
  - Fixed bug #2955058 - Looping over properties during variables
    expansion.
  - Added missing dependency on log4cplus_dll project to filter_test
    project.
  - Added a constructor with Properties parameter to DenyAllFilter.
  - Reworked Layout, Appender and Filter factories registration.

Version 1.0.4-RC5

  - Implemented feature request #2927416 "Add a native Win32 Console
    Appender".
  - Loggingserver now exits with value 2 when it cannot open
    listening socket.
  - Improved Doxygen documentation.
  - Added PropertyConfigurator::getProperties() and
    PropertyConfigurator::getPropertyFilename() functions.
  - Removed LOG4CPLUS_EXPORT on SharedObjectPtr<>.
  - Turned on linker optimizations for MSVC8 builds to make resulting
    binaries slightly smaller.
  - Added --enable-runtime-pseudo-reloc linker option for Cygwin and
    Mingw. Enable --enable-auto-import linker flag also for Mingw.

Version 1.0.4-RC4

  - Fixed bug #2875993 - Implement connector thread for
    SocketAppender.
  - Improved documentation of Appenders' properties.
  - Improved behaviour of DailyRollingFileAppender.
  - Added x64 (AMD64) build configuration to MSVC8 project files.
  - Reworked MSVC8 project files to use .vsprops files to share
    project settings.
  - Moved all tests into Tests project folder.
  - Improved behaviour of ConfigurationWatchDogThread.
  - Fixed bug #2890819 - Handle empty input in towstring_internal()
    and tostring_internal().
  - Corrected VERSION and SOVERSION in CMakeLists.txt.
  - Fixed thread_test compilation on AIX.
  - Added missing syncprims.cxx file in log4cplus_static.vcproj.

Version 1.0.4-RC3

  IMPORTANT: Majority of log4cplus' source code is now licensed using
  the Apache Software License 2.0. The rest is covered by two clause
  BSD license.

  - Fixed bug #2747435. Implement handling of log4cplus.configDebug
    configuration property.
  - Fixed variables shadowing.
  - Doxygen documentation improvements and fixes.
  - Add %i PatternLayout format. It expands to process ID.
  - Fix logging macros compilation for LOG4CPLUS_SINGLE_THREADED case.
  - Fix Logger log level configuration and root Logger handling log
    level handling.

Version 1.0.4-RC2

  - Fixed bug #2834811. Accessing index 0 of empty strings.
  - Fixed bug #2834808. Memory leak in thread local storage code.
  - Removed MSVC6 directory and project files.
  - Update to libtool-2.2.6.

Version 1.0.4-RC1

  - Fixed compilation with Borland C++ Builder compiler.
  - Improved CMake build system to also build tests.
  - Fixed compilation and improved support for Windows CE.
  - Fixed compilation and improved support for Sun Studio 11 compiler.
  - Fixed use after free and improved shutdown handling in
    ConfigurationWatchDogThread.
  - Implement %H (FQDN) and %h (host name) PatternLayout format
    specifiers.
  - Fixed bug #2829604. Environment variables substitution.

Re: [Log4cplus-devel] log4cplus 1.0.4-RC8 released

[Hannah S. <han...@1u...>]

Hello!

On Tue, Jun 01, 2010 at 06:59:45AM +0200, Václav Haisman wrote:
>log4cplus 1.0.4-RC8 has been released. The most interesting changes are
>portability fixes. log4cplus now builds and runs on OpenSolaris compiled
>using Sun C++ compiler. It has also been compiled and tested on
>OpenBSD/AMD64 4.7.

Thanks for the new release. I've got a few patches on it (just rebased
them from RC7), and I'd like to ask whether you'd be ready to consider
them.

The first one would be a compile fix for a compilation error that got
introduced with RC8 (Linux amd64, Debian unstable, gcc 4.4.3), and would
be a quite short patch, so I'd just add it as attachment, based on the
1.0.4 rc8 tarball. If you'd like the patch (or further patches) be
rather based upon the svn trunk, I think I could manage to do that
instead of basing them upon the latest release.

Based on your feedback, I could send you the other patches which would
encompass another fix for a possible problem we noticed here in our
company, and a few feature additions we've come to depend upon here.

Kind regards,

Hannah.

Re: [Log4cplus-devel] log4cplus 1.0.4-RC8 released

[Václav H. <v.h...@sh...>]

Hannah Schroeter wrote, On 1.6.2010 17:37:
> Hello!
> 
> On Tue, Jun 01, 2010 at 06:59:45AM +0200, Václav Haisman wrote:
>> log4cplus 1.0.4-RC8 has been released. The most interesting changes are
>> portability fixes. log4cplus now builds and runs on OpenSolaris compiled
>> using Sun C++ compiler. It has also been compiled and tested on
>> OpenBSD/AMD64 4.7.
> 
> Thanks for the new release. I've got a few patches on it (just rebased
> them from RC7), and I'd like to ask whether you'd be ready to consider
> them.
Yes, I will consider any patches you send.

> 
> The first one would be a compile fix for a compilation error that got
> introduced with RC8 (Linux amd64, Debian unstable, gcc 4.4.3), and would
> be a quite short patch, so I'd just add it as attachment, based on the
> 1.0.4 rc8 tarball. If you'd like the patch (or further patches) be
> rather based upon the svn trunk, I think I could manage to do that
> instead of basing them upon the latest release.
The best for me is if you base the patches on the HEAD revision of e.g.
PRODUCTION_1_0_x branch. But it does not matter much, I can deal with patches
against release source as well.

> 
> Based on your feedback, I could send you the other patches which would
> encompass another fix for a possible problem we noticed here in our
> company, and a few feature additions we've come to depend upon here.
Please send the patches. I will consider each one of them separately. Use
either the mailing list or the patches tracker on SF, whichever is more
comfortable.

--
VH

Re: [Log4cplus-devel] Rest of the patches (was Re: log4cplus 1.0.4-RC8 released)

[Václav H. <v.h...@sh...>]

On Wed, 2 Jun 2010 16:06:21 +0200, Hannah Schroeter wrote:
> Hi!
> 
> On Wed, Jun 02, 2010 at 12:01:33AM +0200, Václav Haisman wrote:
>>[...]
> 
>>Yes, I will consider any patches you send.
> 
>>[...]
> 
>>The best for me is if you base the patches on the HEAD revision of e.g.
>>PRODUCTION_1_0_x branch. But it does not matter much, I can deal with
>>patches
>>against release source as well.
> 
> No problem, rebasing them wasn't difficult.
> 
>>> Based on your feedback, I could send you the other patches which would
>>> encompass another fix for a possible problem we noticed here in our
>>> company, and a few feature additions we've come to depend upon here.
> 
>>Please send the patches. I will consider each one of them separately.
Use
>>either the mailing list or the patches tracker on SF, whichever is more
>>comfortable.
> 
> Sending them here.
> 
> Little explanations.
> 
> 0001 seems to fix a bug for the syslog appender in some cases (if either
> log4cplus uses wstrings and thus LOG4CPLUS_TSTRING_TO_STRING returns a
> temporary, or the identifier is derived from a property, so the
> identifier is always a temporary). At least glibc always stores the
> char* you pass it, instead of copying it by itself.
Applied with minor changes.

> 
> 0002 is a feature addition we needed in house. log4cplus already
> supports logging of the thread ID returned by pthread_self, however, for
> us that wasn't as useful as the gettid() id, as they're different and ps
> shows only the latter (Linux uses 1:1 threading).
I am rejecting this patch. I am not against the idea of this but the
implementation needs some polishing first.

The thread ID needs to be part of the InternalLoggingEvent instance
because the events can be passed around between threads and the thread that
is formatting the output does not have to be the same thread in which the
event has occurred. The thread ID is also not passed through SocketAppender
but you can ignore that, it is a similar situation as with %h/%H format
specifier for host name which does not make it through either.

I think that %T should expand to the same string as %t does when the given
OS does not have any meaningful gettid()-like function.

> 
> 0003 is a feature addition analogous to acces the behavior of
> openlog itself, namely being able to pass the NULL pointer to openlog to
> access a default.
Applied with minor changes.

> 
> 0004 makes the syslog *facility* configurable, instead of only being
> able to use the default (LOG_USER).
Applied with minor changes.

> 
> 0005 makes it possible to limit the depth of the NDC in the pattern
> layout.
I have not had the time to apply the patch, yet, but I think is it looks
ok and I will accept it.

I am going to work on the thread ID patch myself, using yours as a
starting point, but I am going release RC9 first with only the rest of the
patches applied.

Thanks.

--
VH

[Log4cplus-devel] Rest of the patches (was Re: log4cplus 1.0.4-RC8 released)

[Hannah S. <han...@1u...>]

Hi!

On Wed, Jun 02, 2010 at 12:01:33AM +0200, Václav Haisman wrote:
>[...]

>Yes, I will consider any patches you send.

>[...]

>The best for me is if you base the patches on the HEAD revision of e.g.
>PRODUCTION_1_0_x branch. But it does not matter much, I can deal with patches
>against release source as well.

No problem, rebasing them wasn't difficult.

>> Based on your feedback, I could send you the other patches which would
>> encompass another fix for a possible problem we noticed here in our
>> company, and a few feature additions we've come to depend upon here.

>Please send the patches. I will consider each one of them separately. Use
>either the mailing list or the patches tracker on SF, whichever is more
>comfortable.

Sending them here.

Little explanations.

0001 seems to fix a bug for the syslog appender in some cases (if either
log4cplus uses wstrings and thus LOG4CPLUS_TSTRING_TO_STRING returns a
temporary, or the identifier is derived from a property, so the
identifier is always a temporary). At least glibc always stores the
char* you pass it, instead of copying it by itself.

0002 is a feature addition we needed in house. log4cplus already
supports logging of the thread ID returned by pthread_self, however, for
us that wasn't as useful as the gettid() id, as they're different and ps
shows only the latter (Linux uses 1:1 threading).

0003 is a feature addition analogous to acces the behavior of
openlog itself, namely being able to pass the NULL pointer to openlog to
access a default.

0004 makes the syslog *facility* configurable, instead of only being
able to use the default (LOG_USER).

0005 makes it possible to limit the depth of the NDC in the pattern
layout.

Kind regards,

Hannah.

Re: [Log4cplus-devel] Rest of the patches (was Re: log4cplus 1.0.4-RC8 released)

[Václav H. <v.h...@sh...>]

On Wed, 2 Jun 2010 16:06:21 +0200, Hannah Schroeter wrote:
>[...]
> 0005 makes it possible to limit the depth of the NDC in the pattern
> layout.
I have just noticed that the %X format specifier collides with MDC
specifier of log4j. The aim of log4cplus is to be compatible (where
possible) with log4j and overloading the %X like this would go contrary to
the aim. I will be reverting that bit of the patch. Unless you have any
better ideas, I am going to add a property to the PatternLayout through
which it should be possible to set the NDC depth limit. What about
"NDCMaxDepth"?

--
VH

Re: [Log4cplus-devel] Rest of the patches (was Re: log4cplus 1.0.4-RC8 released)

[Hannah S. <han...@1u...>]

Hi!

On Thu, Jun 03, 2010 at 11:16:30AM +0200, Václav Haisman wrote:

>On Wed, 2 Jun 2010 16:06:21 +0200, Hannah Schroeter wrote:

>> On Wed, Jun 02, 2010 at 12:01:33AM +0200, Václav Haisman wrote:
>>>[...]

>>>Yes, I will consider any patches you send.

>>>[...]

>>>The best for me is if you base the patches on the HEAD revision of e.g.
>>>PRODUCTION_1_0_x branch. But it does not matter much, I can deal with
>>>patches
>>>against release source as well.

>> No problem, rebasing them wasn't difficult.

>>>> Based on your feedback, I could send you the other patches which would
>>>> encompass another fix for a possible problem we noticed here in our
>>>> company, and a few feature additions we've come to depend upon here.

>>>Please send the patches. I will consider each one of them separately.
>Use
>>>either the mailing list or the patches tracker on SF, whichever is more
>>>comfortable.

>> Sending them here.

>> Little explanations.

>> 0001 seems to fix a bug for the syslog appender in some cases (if either
>> log4cplus uses wstrings and thus LOG4CPLUS_TSTRING_TO_STRING returns a
>> temporary, or the identifier is derived from a property, so the
>> identifier is always a temporary). At least glibc always stores the
>> char* you pass it, instead of copying it by itself.

>Applied with minor changes.

Thanks.

>> 0002 is a feature addition we needed in house. log4cplus already
>> supports logging of the thread ID returned by pthread_self, however, for
>> us that wasn't as useful as the gettid() id, as they're different and ps
>> shows only the latter (Linux uses 1:1 threading).

>I am rejecting this patch. I am not against the idea of this but the
>implementation needs some polishing first.

>The thread ID needs to be part of the InternalLoggingEvent instance
>because the events can be passed around between threads and the thread that
>is formatting the output does not have to be the same thread in which the
>event has occurred.

Our patch seemed to work for us. So in which cases is the event passed
to different threads before finally being logged?

>The thread ID is also not passed through SocketAppender
>but you can ignore that, it is a similar situation as with %h/%H format
>specifier for host name which does not make it through either.

>I think that %T should expand to the same string as %t does when the given
>OS does not have any meaningful gettid()-like function.

That's a valid concern indeed (as is probably your above one), so I
think your decision to appreciate the idea but to reject the particular
implementation in favor of a better one is valid.

>> 0003 is a feature addition analogous to acces the behavior of
>> openlog itself, namely being able to pass the NULL pointer to openlog to
>> access a default.

>Applied with minor changes.

>> 0004 makes the syslog *facility* configurable, instead of only being
>> able to use the default (LOG_USER).

>Applied with minor changes.

These two commits (r1352, r1353) introduce a useless use of "static" in
the anonymous namespace. See the patch attached.

>> 0005 makes it possible to limit the depth of the NDC in the pattern
>> layout.

>I have not had the time to apply the patch, yet, but I think is it looks
>ok and I will accept it.

Seems you've committed it in-between, at least on the PRODUCTION_1_0_x
branch.

>I am going to work on the thread ID patch myself, using yours as a
>starting point, but I am going release RC9 first with only the rest of the
>patches applied.

>Thanks.

Thank you too.

Kind regards,

Hannah.

Re: [Log4cplus-devel] Rest of the patches (was Re: log4cplus 1.0.4-RC8 released)

[Václav H. <v.h...@sh...>]

On Mon, 7 Jun 2010 12:57:59 +0200, Hannah Schroeter wrote:
> Hi!
> 
> On Thu, Jun 03, 2010 at 11:16:30AM +0200, Václav Haisman wrote:
> 
>>On Wed, 2 Jun 2010 16:06:21 +0200, Hannah Schroeter wrote:
> 
>>> On Wed, Jun 02, 2010 at 12:01:33AM +0200, Václav Haisman wrote:
>>>>[...]
> 
>>>>Yes, I will consider any patches you send.
> 
>>>>[...]
> 
>>>>The best for me is if you base the patches on the HEAD revision of
e.g.
>>>>PRODUCTION_1_0_x branch. But it does not matter much, I can deal with
>>>>patches
>>>>against release source as well.
> 
>>> No problem, rebasing them wasn't difficult.
> 
>>>>> Based on your feedback, I could send you the other patches which
would
>>>>> encompass another fix for a possible problem we noticed here in our
>>>>> company, and a few feature additions we've come to depend upon here.
> 
>>>>Please send the patches. I will consider each one of them separately.
>>Use
>>>>either the mailing list or the patches tracker on SF, whichever is
more
>>>>comfortable.
> 
>>> Sending them here.
> 
>>> Little explanations.
> 
>>> 0001 seems to fix a bug for the syslog appender in some cases (if
either
>>> log4cplus uses wstrings and thus LOG4CPLUS_TSTRING_TO_STRING returns a
>>> temporary, or the identifier is derived from a property, so the
>>> identifier is always a temporary). At least glibc always stores the
>>> char* you pass it, instead of copying it by itself.
> 
>>Applied with minor changes.
> 
> Thanks.
> 
>>> 0002 is a feature addition we needed in house. log4cplus already
>>> supports logging of the thread ID returned by pthread_self, however,
for
>>> us that wasn't as useful as the gettid() id, as they're different and
ps
>>> shows only the latter (Linux uses 1:1 threading).
> 
>>I am rejecting this patch. I am not against the idea of this but the
>>implementation needs some polishing first.
> 
>>The thread ID needs to be part of the InternalLoggingEvent instance
>>because the events can be passed around between threads and the thread
>>that
>>is formatting the output does not have to be the same thread in which
the
>>event has occurred.
> 
> Our patch seemed to work for us. So in which cases is the event passed
> to different threads before finally being logged?
There is not a place in 1.0.x source that passes events between threads.
There is such place in 1.1.x (AsyncAppender). And I know there are people
with who are using their own appenders in which case there is a possibility
they pass events between threads.

> 
>>The thread ID is also not passed through SocketAppender
>>but you can ignore that, it is a similar situation as with %h/%H format
>>specifier for host name which does not make it through either.
> 
>>I think that %T should expand to the same string as %t does when the
given
>>OS does not have any meaningful gettid()-like function.
> 
> That's a valid concern indeed (as is probably your above one), so I
> think your decision to appreciate the idea but to reject the particular
> implementation in favor of a better one is valid.
> 
>>> 0003 is a feature addition analogous to acces the behavior of
>>> openlog itself, namely being able to pass the NULL pointer to openlog
to
>>> access a default.
> 
>>Applied with minor changes.
> 
>>> 0004 makes the syslog *facility* configurable, instead of only being
>>> able to use the default (LOG_USER).
> 
>>Applied with minor changes.
> 
> These two commits (r1352, r1353) introduce a useless use of "static" in
> the anonymous namespace. See the patch attached.
I agree that at first glance they are useless and go contrary to what the
C++ standard suggests. But they have a meaning. Symbols in anonymous
namespace have external linkage. In older Cygwin versions and on systems
that do not have GCC's -fvisibility=hidden support such symbols get
exported in shared objects/DLLs. Adding the static keyword removes them
from the exports.

> 
>>> 0005 makes it possible to limit the depth of the NDC in the pattern
>>> layout.
> 
>>I have not had the time to apply the patch, yet, but I think is it looks
>>ok and I will accept it.
> 
> Seems you've committed it in-between, at least on the PRODUCTION_1_0_x
> branch.
> 
>>I am going to work on the thread ID patch myself, using yours as a
>>starting point, but I am going release RC9 first with only the rest of
the
>>patches applied.
> 
>>Thanks.
> 
> Thank you too.

--
VH