Hi Matt,
That was it. Works now, thanks.
/David
On Sun, Jul 20, 2014 at 10:45 PM, Matt Sicker boa...@gmail.com wrote:
You need to add log4j-nosql to your classpath. It was separated from
log4j-core due to its, uh, non-core-ness.
On 20 July 2014 15:25, David KOCH dk...@ezakus.com wrote:
Thanks Matt. This is working after enabling annotation processing and
adding the log4j2 core jar file to the so called factory path in Eclipse. I
think this should go into the official documentation.
On 20 July 2014 22:45, Matt Sicker boa...@gmail.com wrote:
You'll have to enable annotation
Hello Remko,
I think I found the difference. AsyncLoggerContextSelector always returns
the same instance of AsyncLoggerContext, which in turns always returns
instances of AsyncLogger, which uses disruptor to handle concurrency.
However, with any other selector, a standard Logger instance is
Hi,
No that is incorrect.
If you do not specify AsyncLoggerContextSelector but instead configure with
AsyncRoot and AsyncLogger loggers, you _do_ need the disruptor jar on
the classpath and this does _not_ use AsyncAppender. AsyncAppender is
completely separate from Async Loggers. Async Loggers
I think he's talking about the ClassLoaderContextSelector which attempts to
find the logger context through several different ways. Using the
sun.reflect.Reflection class to get the caller class itself is one of those
techniques which might slow things down a little.
I actually have a change to
Hello Remko,
I'm still a couple of days away from starting my own performance testing.
I'm taking about the difference in the async loggers manual page, more
specifically, the charts that compare sync loggers, to mixed async loggers
against purely async loggers. Since I need to build my own
Well, the way to go that's similar to the async version is to use the
BasicContextSelector which contains a singleton LoggerContext. Otherwise,
you'll have to keep your own registry that can be looked up dynamically
such as through reflection of the caller stack and other fun design
problems. :)
Matt, not sure what you mean. Mariano needs to develop his own
ContextSelector to achieve log separation.
So he cannot use the AsyncLoggerContextSelector.
Mariano, I would not be overly concerned with the performance results
mentioned on the async logger manual page. Bear in mind that in that
Mariano, to clarify, I would recommend that you keep your custom context
selector simple and only use it for the log separation that you mentioned.
I would not recommend that you also somehow try to merge the functionality
of AsyncLoggerContextSelector in your context selector. From a performance
Thanks Remko and Matt for your comments.
I will take your suggestions and let you know how it goes.
Just out of curiosity (I don't like to use libraries blindly and way too
curious), where are the loggers instantiated/configured?? I followed the
code of XmlConfiguration but it seems to only
Take a look at http://logging.apache.org/log4j/2.x/manual/architecture.html.
The configuration creates the LoggerConfig objects, not the Loggers. Loggers
are created by applications and associated with LoggerConfigs.
XMLConfiguration and JSONConfiguration are responsible for parsing their
11 matches
Mail list logo
