Re: reusing a logger+appender

2018-02-14 Thread Ralph Goers
That is interesting. We had an email earlier this week from someone who had a log4j2.xml in a jar they couldn’t modify. He called that “EVIL.jar”. That said, I could understand including a log4j2-mycomponent.xml that gets merged with the application’s logging configuration. If you do that you ju

Re: reusing a logger+appender

2018-02-14 Thread Benjamin Jaton
Yes I have been using the composite config feature, it does help. It would be nice to be able to configure the logging of a component in the component itself, instead of having to add it in the initial logging configuration of all the potential applications that might use it. In particular if some

Re: reusing a logger+appender

2018-02-07 Thread Ralph Goers
Are you saying you want to merge a new configuration with the existing one? Log4j supports a composite configuration but the files that make up the composite have to be known from the beginning. Ralph > On Feb 7, 2018, at 6:22 PM, Benjamin Jaton wrote: > > I am specifically asking about how t

Re: reusing a logger+appender

2018-02-07 Thread Benjamin Jaton
I am specifically asking about how to feed that conf in the log4j2 engine, are there methods to enrich the existing log4j2 appenders/loggers? On Wed, Feb 7, 2018 at 4:37 PM, Matt Sicker wrote: > You could potentially use JNDI to load and store your configuration if > using Java EE. Otherwise, yo

Re: reusing a logger+appender

2018-02-07 Thread Matt Sicker
You could potentially use JNDI to load and store your configuration if using Java EE. Otherwise, you could also set the config file name system property to locate a common config file (at least through the local file system or class path). On Wed, Feb 7, 2018 at 18:01, Benjamin Jaton wrote: > He

reusing a logger+appender

2018-02-07 Thread Benjamin Jaton
Hello, I would like to have a piece of code use Log4J2 to log events in a CSV format. So the appender and logger configuration are specific to this task. The problem is that there are several JVMs that might invoke this task (not at the same time though). Therefore I would think that each of thos