You have two root loggers. Only one of them is going to take effect. The other
should have generated an error but it sounds like it didn't. That is a bug and
needs to be fixed.
It sounds like the second root logger is winning and so all messages except
those marked as trace will go to the
it would be nice to have thread debug level. why? we have 80% code that
is shared in one data center by 25 customers.
now when we make changes that affect at most 2-3 customers or add a new
one, its nice to have more debug for that customer. most of our classes
are multi customer and the only
This is possible now. Please see
http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter.
If you add the user's loginid to the ThreadContextMap you can filter users at
different logging levels.
Ralph
On Mar 14, 2013, at 3:03 AM, Tushar Kapila wrote:
it would be nice
(I fixed some missing pretty print for one of the XML documents, in SVN)
Gary
On Thu, Mar 14, 2013 at 9:59 AM, Ralph Goers ralph.go...@dslextreme.comwrote:
This is possible now. Please see
http://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter.
If you add the user's
Thanks Ralph, that clears up a lot of confusion.
I still have another question about properties files. In log4j 1.2, we can use
a
regular file in the style of attribute=value. Are we still able to do that
in log4j2? Or, has JSON/XML become the standards and preferred options?
I have not implemented support for properties files in Log4j 2. It would be
fairly easy to implement but I've never really liked the way they worked in
Log4j 1.x so I just didn't do it. I prefer XML but at an ApacheCon a couple of
years ago I was encouraged to support JSON and since it
