Ok, what I am hearing is that you'd rather I keep the
updateLoggers(Appender appender) method in my own code? I'll defer to you
on this. I do see callers of addAppender(3 args) that almost do the same
thing I am doing. But not the exactly same...

Gary
On Oct 30, 2015 2:21 PM, "Ralph Goers" <[email protected]> wrote:

> I am not in favor of updateLoggers(Appender appender). In my experience it
> is the exception rather than the rule to want to add an appender to all
> your configured loggers.  Most of the time Loggers either a) set the level
> and fall through to a parent or b) reference different appenders.   I would
> prefer that the user should have to code that loop if that is really what
> they want to do.
>
> The purpose of updateLoggers(configuration) is to cause all the Loggers to
> refresh their LoggerConfig references and levels. It is the call that
> actually binds the Loggers to a new configuration.
>
> Ralph
>
> On Oct 30, 2015, at 2:02 PM, Gary Gregory <[email protected]> wrote:
>
> It seems I was mislead by the method updateLoggers(Configuration). Then
> this means I have to go through all LC's and add the new appender to each,
> that's OK. Here is what I have locally then:
>
>     @Test
>     public void test() {
>         final LoggerContext ctx = (LoggerContext)
> LogManager.getContext(false);
>         final Configuration config = ctx.getConfiguration();
>         Layout<?> layout = PatternLayout.createDefaultLayout();
>         Appender appender = FileAppender.createAppender("target/test.log",
> "false", "false", "File", "true", "false",
>                 "false", "4000", layout, null, "false", null, config);
>         appender.start();
>         config.addAppender(appender);
>         config.updateLoggers(appender);
>         LogManager.getLogger().error("FOO MSG");
>     }
>
> And in AbstractConfiguration (and defined in Configuration):
>
>     @Override
>     public void updateLoggers(final Appender appender) {
>         final Level level = null;
>         final Filter filter = null;
>         for (LoggerConfig loggerConfig : getLoggers().values()) {
>             loggerConfig.addAppender(appender, level, filter);
>         }
>         getRootLogger().addAppender(appender, level, filter);
>     }
>
>
> WDYT?
>
> My tests pass with that.
> Gary
>
> On Thu, Oct 29, 2015 at 9:49 PM, Ralph Goers <[email protected]>
> wrote:
>
>> Gary,
>>
>> Your sample code below isn’t modifying any LoggerConfigs to reference the
>> new Appender.  How did you expect an error message to get to it?
>>
>> Ralph
>>
>> On Oct 29, 2015, at 5:24 PM, Gary Gregory <[email protected]> wrote:
>>
>> Yes, like I noted below, the example creates an empty file instead of a
>> file with an ERROR message.
>>
>> It looks like the LoggerConfig that is in the DefaultReliabilityStrategy
>> is not updated when LoggerContext.updateLogger() is called.
>>
>> I could swear I had this example working a while back. Could this be a
>> regression due to the introduction of ReliabilityStrategy?
>>
>> The DefaultReliabilityStrategy is also hard coded in some LoggerConfig
>> ctors. Is that correct? Especially since we have pluggable
>> ReliabilityStrategy implementations?
>>
>> Gary
>>
>>
>> On Thu, Oct 29, 2015 at 5:15 PM, Ralph Goers <[email protected]>
>> wrote:
>>
>>> I imagine that we added more parameters to some of the methods since it
>>> was first published.
>>>
>>> What do you mean by "it doesn’t work”? Are you getting an exception?
>>> Since no Loggers were modified to point to your new appender I am thinking
>>> all it is going to do is create an empty file. This seems like a follow-on
>>> to our discussion in the Jira issue about the PrintStream where you were
>>> doing the same thing.
>>>
>>> Ralph
>>>
>>> On Oct 29, 2015, at 4:58 PM, Gary Gregory <[email protected]>
>>> wrote:
>>>
>>> Our nice example "Programmatically Modifying the Current Configuration
>>> after Initialization" does not work. (The PatternLayout.create() call does
>>> not compile too).
>>>
>>> I've simplified it to:
>>>
>>>     @Test
>>>     public void test() {
>>>         final LoggerContext ctx = (LoggerContext)
>>> LogManager.getContext(false);
>>>         final Configuration config = ctx.getConfiguration();
>>>         Layout<?> layout = PatternLayout.createDefaultLayout();
>>>         Appender appender =
>>> FileAppender.createAppender("target/test.log", "false", "false", "File",
>>> "true", "false",
>>>                 "false", "4000", layout, null, "false", null, config);
>>>         appender.start();
>>>         config.addAppender(appender);
>>>         ctx.updateLoggers();
>>>         LogManager.getLogger().error("FOO MSG");
>>>     }
>>>
>>> and it creates an empty file.
>>>
>>> What am I missing? The test class has nothing else in it.
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: [email protected] | [email protected]
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: [email protected] | [email protected]
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: [email protected] | [email protected]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>

Reply via email to