You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2015/10/30 00:58:11 UTC
Programmatically Modifying the Current Configuration after Initialization
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: garydgregory@gmail.com | ggregory@apache.org
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
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@gmail.com>
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" <ra...@dslextreme.com> 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 <ga...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 <ga...@gmail.com>
>>> 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 <ralph.goers@dslextreme.com
>>> > 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 <ga...@gmail.com>
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
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" <ra...@dslextreme.com> 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 <ga...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <ga...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 <ga...@gmail.com>
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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
>
>
>
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>> 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 <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>> 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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> 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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
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 <ra...@dslextreme.com>
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 <ga...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <ga...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>> 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 <http://garygregory.wordpress.com/>
>> Home: http://garygregory.com/ <http://garygregory.com/>
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> 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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
I'm looking
at org.apache.logging.log4j.core.Logger.PrivateConfig.PrivateConfig(Configuration,
Logger) and wondering how the loggerConfig in a ReliabilityStrategy can be
updated? It can't, it's final. So that leaves us with recreating the RS on
an updateLoggers() call, but how? Is that the right place to save the RS in
the first place? It's in the configuration's configuration monitor as a
nice "one place" to find it.
Any help appreciated...
Gary
On Thu, Oct 29, 2015 at 7:08 PM, Gary Gregory <ga...@gmail.com>
wrote:
> It's the other way around, none of the ctors are called from tests, only
> from main code.
>
> Gary
> On Oct 29, 2015 5:33 PM, "Remko Popma" <re...@gmail.com> wrote:
>
>> Those constructors are only called from tests if I remember correctly.
>>
>> Sent from my iPhone
>>
>> On 2015/10/30, at 9:24, Gary Gregory <ga...@gmail.com> 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 <ra...@dslextreme.com>
>> 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 <ga...@gmail.com>
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
It's the other way around, none of the ctors are called from tests, only
from main code.
Gary
On Oct 29, 2015 5:33 PM, "Remko Popma" <re...@gmail.com> wrote:
> Those constructors are only called from tests if I remember correctly.
>
> Sent from my iPhone
>
> On 2015/10/30, at 9:24, Gary Gregory <ga...@gmail.com> 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 <ra...@dslextreme.com>
> 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 <ga...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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
>
>
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Remko Popma <re...@gmail.com>.
Those constructors are only called from tests if I remember correctly.
Sent from my iPhone
> On 2015/10/30, at 9:24, Gary Gregory <ga...@gmail.com> 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 <ra...@dslextreme.com> 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 <ga...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Gary Gregory <ga...@gmail.com>.
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 <ra...@dslextreme.com>
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 <ga...@gmail.com> 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: garydgregory@gmail.com | ggregory@apache.org
> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: Programmatically Modifying the Current Configuration after Initialization
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> 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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> 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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>