OK, I'm sure all of that is fine. Les wrote one for log4cplus and I changed the file when we moved over to log4cxx. He asked me to submit it for him because he's so busy at the moment.

The amount of "clever" code in there is almost zero, so I don't care what is done or how it is altered, I just the need the facility in order to be able to use log4cxx at all! OutputDebugString is a key feature for us. :)

DP

--On 10 August 2004 10:55 -0500 Curt Arnold <[EMAIL PROTECTED]> wrote:


On Aug 10, 2004, at 6:11 AM, Danny Pike wrote:

I sent it off but nothing happened, as far as I can see. I don't know
how long it takes for these things to get added. I get the impression
that it is rather too much for the team to handle :)

DP

I've added a bug for this feature request:
http://nagoya.apache.org/jira/browse/LOGCXX-6

I had a couple of issues with the submitted patch, however the idea and
general approach appear solid.

First, there is not an equivalent appender in log4j, however log4net's
equivalent is called OutputDebugStringAppender.  To try to keep
compatibility between the configuration files, that name should also be
used in log4cxx.

Michaël may have a better feel for significance of this, but the
submitted patch had a personal copyright that was not the same name as
the submitter.  I'm pretty sure that we want to keep all copyrights in
the code assigned to the Apache Software Foundation, but I'm unsure the
submission is sufficient basis to rework the copyright assignment.

There was a comment that said that all LF's  were replaced by CR-LF's,
however the code appeared only to change the final one.  I did not see an
equivalent in the log4net implementation.  Could someone elaborate the on
scenarios (log requests and debuggers) that motivated the replacement?

With the proposed implementation, I assume that if a configuration file
with a OutputDebugStringAppender would fail to load on a non-Windows
platform.  I'm not sure if that is a desirable behavior.  An alternative
would be for OutputDebugStringAppender to do nothing on platforms that do
not support an equivalent functionality.

Probably easier for Michaël or I to do a clean implementation since it is
fairly trival, basically render the logging event to a string and call
OutputDebugString.








Reply via email to