I will have to create an example. Ralph
On Aug 14, 2013, at 8:27 AM, Gary Gregory wrote: > On Wed, Jul 24, 2013 at 12:22 PM, Gary Gregory <[email protected]>wrote: > >> On Mon, Jul 22, 2013 at 5:59 PM, Ralph Goers >> <[email protected]>wrote: >> >>> Well, you can actually do that. It is just not my number one >>> recommendation :-) I'm pretty sure I have answered how to do that a few >>> times. It just needs to be documented. >>> >>> The actual code to do this is >>> >>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false); >>> >>> Configuration config = ctx.getConfiguration(); >>> >>> LoggerConfig loggerConfig = config.getLoggerConfig(loggerName); >>> >>> loggerConfig.setLevel(level); >>> >>> ctx.updateLoggers(); >>> >>> Note that the LoggerConfig returned may not match loggerName - it might >>> be a parent. >> >> >> Wait a sec. So I f have two loggers "A.X" and "A.Y" and I call >> config.getLoggerConfig("A.X") I might return "A" and I will end up setting >> the log level for both "A.X" AND "A.Y"? >> >> That's not what anyone will want, at least not me. Did I misunderstand you? >> >> The question then is, how do I use the Core API to set the log level for a >> specific logger. >> >> Gary >> > > ping? > > Gary > > >> >> >>> Also, adding a new LoggerConfig to an existing configuration is not >>> allowed as it cannot be done atomically. In that case you have to create a >>> new configuration. >>> >>> Ralph >>> >>> >>> On Jul 22, 2013, at 2:04 PM, Nicholas Williams wrote: >>> >>>> I can live with having to use the Core directly to change logger >>>> levels, as opposed to using the API. But your solution of cloning, >>>> changing, and replacing the configuration seems extremely heavy and >>>> excessive for merely changing the level for a single logger. There are >>>> a lot of other things that happen as a result that are completely >>>> unrelated to changing the level for a logger. >>>> >>>> Note that org.apache.log4j.Logger from Log4j 1 includes a setLevel >>>> method. While I understand that Log4j 1 isn't a separated >>>> API/implementation like Log4j 2, users are used to being able to >>>> easily change Logger levels, and you WILL (I'm confident) start seeing >>>> "Why is this so hard" questions when Log4j 1 sunsets and users start >>>> migrating en masse. >>>> >>>> On Mon, Jul 22, 2013 at 3:48 PM, Ralph Goers < >>> [email protected]> wrote: >>>>> I guess I have to disagree. With Logback it is more explicit since >>> SLF4J is its API. The more of this stuff that gets added to the API the >>> more difficult it is going to be to keep the API separate from the >>> implementation. My view is that the API is primarily for applications that >>> want to use Log4j to generate Log events. Doing things to customize how >>> Appenders, Loggers, Filters, etc work is very much tied to the >>> implementation. Note that none of those are exposed in the API today and >>> you would have to to do what you are proposing. >>>>> >>>>> Ralph >>>>> >>>>> On Jul 22, 2013, at 12:56 PM, Gary Gregory wrote: >>>>> >>>>>> This seems like an "obvious" feature and should be part of the public >>>>>> API/feature set (IMO). >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> On Mon, Jul 22, 2013 at 3:08 PM, Nick Williams < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> We do the _exact same thing_ in our apps that use Log4j 1. Being >>> able to >>>>>>> do this is crucial to us. Being able to do this using the API is >>> ideal and >>>>>>> obviously preferred so that the Core can be a runtime dependency, >>> but as >>>>>>> long as we can do it one way or another we're ok. >>>>>>> >>>>>>> Nick >>>>>>> >>>>>>> On Jul 22, 2013, at 2:05 PM, Gary Gregory wrote: >>>>>>> >>>>>>>> Here is a user story I have at work all the time, which I'd like to >>> be >>>>>>> able >>>>>>>> to do in Log4J 2 when we eventually migrate to it. >>>>>>>> >>>>>>>> Our server starts. A couple of days later, something goes wrong. >>> Our user >>>>>>>> contacts us and we tell them to use our admin console to enable >>> debugging >>>>>>>> for X and Y. This causes the log levels for certain loggers to be >>> set to >>>>>>>> DEBUG, which spits out lots of details. The user then sends us the >>> log >>>>>>> file >>>>>>>> and resets the system to normal. Under the covers the loggers go >>> back to >>>>>>>> INFO or WARN. >>>>>>>> >>>>>>>> Our console sends a request to the server, which in turns uses the >>> log4j >>>>>>> 1 >>>>>>>> API to change the log level. >>>>>>>> >>>>>>>> How would I do that in v2? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 22, 2013 at 1:55 PM, Ralph Goers < >>> [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Can you explain what it is you are really trying to do? Rather >>> than >>>>>>> just >>>>>>>>> answer specific questions I am wondering if there isn't a better >>> way to >>>>>>> do >>>>>>>>> what you want. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jul 22, 2013, at 7:14 AM, SMITH, CURTIS wrote: >>>>>>>>> >>>>>>>>>> From a thread back in May: >>>>>>>>>> >>>>>>>>>> My question to the below snips of the thread are; >>>>>>>>>> >>>>>>>>>> My app has many Catagories (using 1.x terminology). To setLevel >>> in 1.x >>>>>>>>> I had to getCurrentCatagories() and iterate over the list setting >>> level. >>>>>>>>>> >>>>>>>>>> In 2.x, does the code below set all Appenders regardless of what >>> Level >>>>>>>>> they were set to in log4j.xml? >>>>>>>>>> >>>>>>>>>> loggerConfig.setLevel(Level.DEBUG); >>>>>>>>>> ctx.updateLoggers(); >>>>>>>>>> >>>>>>>>>> The next question is how to set the level of just one Appender >>>>>>>>> (Logger??) ? Is there a way to get the list / iterator of >>>>>>>>> Appenders(Logger?) like you could get a a list of Catagories in >>> 1.x? >>>>>>>>>> >>>>>>>>>> It appears that LogManager.getLogger("foo") you need to know the >>> logger >>>>>>>>> names at coding time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, curt >>>>>>>>>> >>>>>>>>>> ======= >>>>>>>>>> >>>>>>>>>> Ralph Goers said: >>>>>>>>>>>> No, the X Logger does not inherit its level from the root >>> Logger. It >>>>>>>>> inherits its level from >>>>>>>>>> the root LoggerConfig. See the picture at >>>>>>>>> http://logging.apache.org/log4j/2.x/manual/architecture.html. >>>>>>>>>> >>>>>>>>>> The level you are modifying is brought into each Logger so that >>> the >>>>>>>>> level can be tested very >>>>>>>>>> quickly. That is why the note on the setLevel method says it is >>>>>>>>> there primarily for unit >>>>>>>>>> testing. >>>>>>>>>> >>>>>>>>>> To do what you are attempting below you would need to do: >>>>>>>>>> >>>>>>>>>> LoggerContext ctx = (LoggerContext) >>> LogManager.getContext(false); >>>>>>>>>> Configuration config = ctx.getConfiguration(); >>>>>>>>>> LoggerConfig loggerConfig = config.getRootLogger(); >>>>>>>>>> /* You could also specify the actual logger name as below and it >>>>>>>>> will return the LoggerConfig >>>>>>>>>> used by the Logger. >>>>>>>>>> LoggerConfig loggerConfig = getLoggerConfig("X"); >>>>>>>>>> */ >>>>>>>>>> loggerConfig.setLevel(Level.DEBUG); >>>>>>>>>> ctx.updateLoggers(); // This causes all Loggers to refetch >>>>>>>>> information from their LoggerConfig. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>> Eric Scheie said: >>>>>>>>>>>> This >>>>>>>>>> is the actual code I used. >>>>>>>>>> >>>>>>>>>> LoggerContext ctx = (LoggerContext) >>> LogManager.getContext(false); >>>>>>>>>> >>>>>>>>>> Configuration config = ctx.getConfiguration(); >>>>>>>>>> >>>>>>>>>> LoggerConfig loggerConfig = config.getLoggerConfig(LogManager. >>>>>>>>>> ROOT_LOGGER_NAME); >>>>>>>>>> >>>>>>>>>> loggerConfig.setLevel(level); >>>>>>>>>> >>>>>>>>>> ctx.updateLoggers(); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>> For additional commands, e-mail: >>> [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: >>> [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
