Re: Non-Root Logger Logging Problems

[Robert Middleton]

Hi Nathan,

My guess would be that additivity.sender=false should actually be
sender.additivity=false.

As to why the log messages are not going to the second FileAppender,
I'm not sure why that would be happening.  I would recommend running
with internal debugging enabled.  You can do this by setting
log4j.debug=true in your config file.

-Robert Middleton



On Wed, Nov 30, 2022 at 11:41 PM Eisenberg, Nathan
 wrote:
>
> I have configured 2 loggers inside my java config file: 1 is the rootLogger 
> and it has 2 appenders, and the other is called sender and it has 1 appender.
>
>
> My java config file looks something like this:
> rootLogger= [level], consoleAppender, fileAppender1
>
> sender=[level], fileAppender2
> additivity.sender=false
>
> consoleAppender=log4j.consoleAppender
> layout stuff...
>
> fileAppender1=log4j.RollingFileAppender
> file and layout details...
>
> fileAppender2=log4j.RollingFileAppender
> file and layout details...
>
>
> And in my c++ code I'm using it like this:
> Logger rootLogger = getLogger("root");
> LOG4CXX_INFO(rootLogger, "message");
>
> Logger senderLogger = getLogger("sender");
> LOG4CXX_INFO(senderLogger, "otherMessage");
>
>
> Although the rootAppender works perfectly fine, my problem is that the 
> sender's message (otherMessage) is only showing up in the rootLogger's 
> appenders (consoleAppender, fileAppender1) but NOT it's own appender 
> (fileAppender2). Does anyone have any idea what I'm doing wrong?
>
>
> Nathan Eisenberg
>

RE: EXTERNAL: Re: Non-Root Logger Logging Problems

[Eisenberg, Nathan]

Hey Robert,

Thanks for getting back to me so quickly.

Running with debug helped me figure it out. It looks like the additivity stuff 
was right the way it was, but it turns out when it was parsing the log file it 
wasn't even noticing the other loggers. So I looked even closer and noticed 
that I was saying "log4" instead of "log4j" just on the lines where I was 
defining sender and receiver. I can't believe I didn't see that before posting, 
but thank you for helping me find it.

Best,
Nathan Eisenberg

-Original Message-
From: Robert Middleton  
Sent: Thursday, December 1, 2022 7:31 AM
To: dev@logging.apache.org
Subject: EXTERNAL: Re: Non-Root Logger Logging Problems

Hi Nathan,

My guess would be that additivity.sender=false should actually be 
sender.additivity=false.

As to why the log messages are not going to the second FileAppender, I'm not 
sure why that would be happening.  I would recommend running with internal 
debugging enabled.  You can do this by setting log4j.debug=true in your config 
file.

-Robert Middleton



On Wed, Nov 30, 2022 at 11:41 PM Eisenberg, Nathan  
wrote:
>
> I have configured 2 loggers inside my java config file: 1 is the rootLogger 
> and it has 2 appenders, and the other is called sender and it has 1 appender.
>
>
> My java config file looks something like this:
> rootLogger= [level], consoleAppender, fileAppender1
>
> sender=[level], fileAppender2
> additivity.sender=false
>
> consoleAppender=log4j.consoleAppender
> layout stuff...
>
> fileAppender1=log4j.RollingFileAppender
> file and layout details...
>
> fileAppender2=log4j.RollingFileAppender
> file and layout details...
>
>
> And in my c++ code I'm using it like this:
> Logger rootLogger = getLogger("root"); LOG4CXX_INFO(rootLogger, 
> "message");
>
> Logger senderLogger = getLogger("sender"); LOG4CXX_INFO(senderLogger, 
> "otherMessage");
>
>
> Although the rootAppender works perfectly fine, my problem is that the 
> sender's message (otherMessage) is only showing up in the rootLogger's 
> appenders (consoleAppender, fileAppender1) but NOT it's own appender 
> (fileAppender2). Does anyone have any idea what I'm doing wrong?
>
>
> Nathan Eisenberg
>

Re: [log4cxx] fmt compiling/linking issue

[Robert Middleton]

It looks like I was overcomplicating this.  The constructor for a
std::chrono::time_point does take in a duration from the clock's
epoch, which is ultimately what we want to do.

PR up on github for review.

-Robert Middleton

On Sat, Nov 26, 2022 at 11:10 PM Stephen Webb  wrote:
>
> Fmt seems to have a formatter for std::chrono::time_point templated by
> std::chrono::system_clock and (optionally) std::chrono::utc_clock if my
> interpretation of the fmt/chrono.h code in the https://github.com/fmtlib
> master branch is correct.
>
> Quoting from https://en.cppreference.com/w/cpp/chrono/high_resolution_clock
> >
> > It may be an alias of std::chrono::system_clock
> >  or
> > std::chrono::steady_clock
> > , or a third,
> > independent clock.
>
>
> On Sun, Nov 27, 2022 at 2:14 AM Robert Middleton 
> wrote:
>
> > Odd.  How would we format the timestamp in that case?  According to
> > the documentation, fmt has formatters for std::chrono::time_point
> > already.
> >
> > Is this some sort of difference between MSVC and gcc?  It should be
> > trying to format
> > std::chrono::time_point, which I
> > thought was std::chrono::system_clock instead of steady_clock.
> >
> > -Robert Middleton
> >
> >
> > On Fri, Nov 25, 2022 at 11:03 PM Stephen Webb  wrote:
> > >
> > >  In Visual studio 2019 the line
> > >
> > > fmt::arg("d", event->getChronoTimeStamp()),
> > >
> > >
> > > causes the compile time error:
> > >
> > > error C2338: Cannot format an argument. To make type T formattable
> > provide
> > > a formatter specialization: https://fmt.dev/latest/api.html#udt
> > >
> > >
> > > It seems to need a formatter  specialization for
> > > std::chrono::steady_clock::time_point.
> > >
> > > The branch build OK with the above line commented out.
> > >
> > > On Sat, Nov 26, 2022 at 2:13 AM Robert Middleton 
> > > wrote:
> > >
> > > > I've been working on LOGCXX-514(using fmt as an alternative layout to
> > > > the PatternLayout) and I've got a working implementation on Linux.
> > > > However, the Windows build currently fails with some sort of symbol or
> > > > linking error.  Since I'm not all that familiar with Windows, would
> > > > somebody with more experience on the Windows side be able to take a
> > > > look at it?
> > > >
> > > > I suspect that this could also be something to do with the wchar on
> > > > Windows, but it is not clear to me if that is the case or not.
> > > >
> > > > -Robert Middleton
> > > >
> >