OK, I'm all set WRT this thread. I have an updateLoggers() method in our
unit tests and I'll add such a method in my own JDBC driver code.

Gary

On Fri, Oct 30, 2015 at 2:26 PM, Gary Gregory <[email protected]>
wrote:

> 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
>>
>>
>>


-- 
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