Blaine,

First a small detail: you will find that the entry(), exit() and catching() 
methods are only useful if you configure includeLocation="true" (there is a 
performance trade-off here, the manual has more details).

Next, I'm not sure about what you want to achieve by changing the log level 
based on which user is using your app. Personally I would advise against that; 
I would keep it simple, and just have a single configuration that logs 
everything at a level of detail that allows you to work out what went wrong if 
something unexpected happens. To me, that means logging everything at TRACE 
level because we can't reproduce the issue without enough information. (This 
may be different for different applications.)

Bear in mind, your users will never see the logs, only your first level support 
team and (if they can't figure out the problem), your second level support 
(probably your development team) will ever look at the log files. 

Best regards,
Remko

Sent from my iPhone

> On 2015/01/16, at 2:54, "Blaine Bergeson (bbergeson)" <[email protected]> 
> wrote:
> 
> Hi,
> 
> I am just getting started using Log4j2 and after pouring over the 
> documentation which is pretty good I would still like some assurance that I 
> am heading the right direction.  I feel like my use case is the most 
> fundamental case but there must be a slicker way than how I am implementing 
> it.
> 
> I only need one log file for my entire application(isn't this true for most 
> applications?); therefore I am using the root logger with the level set at 
> info, and 1 Async RollingRandomAccessFile appender.  My understanding of 
> logging up to this point has been, add logging statements all over the place 
> using entry(), exit(), debug(), info(), etc.,  and then based upon the type 
> of user that is using the application, programmatically change the logging 
> level so that the correct events are allowed to be logged for that type of 
> user.  Outside of wanting to use a different pattern or appender based  upon 
> some criteria, other than the level, why wouldn't you always want to do it 
> this way?  It seems like the configuration file is just used to define the 
> destinations and patterns based upon some critiera, but the most basic 
> typical use case is to change the log level based upon a user or mode of the 
> application.  Another words as far as the logging level is concerned it seems 
> like the configuration file just contains some default value but then in my 
> code I have to get the context, then get the configuration, then get the root 
> logger config, set the new log level, and finally update all the loggers 
> every time I want to change what is logged based upon some mode or user.  I 
> can pass the user name or mode to the configuration by way of the context map 
> but then what do I put in the configuration to allow certain events to be 
> logged if it is a certain log level or more specific?
> 
> For example given the following user types I would the logging level to 
> change, and the user type can change at any time while the application is 
> running:
> 
> General User:  log level should be ERROR so error and more specific events 
> are logged
> Support User: log level should be INFO so info and more specific events are 
> logged
> Advanced User: log level should be DEBUG so debug and more specific events 
> are logged
> Developer:  log level should be TRACE so trace and more specific events are 
> logged
> 
> What am I missing?  Is there a "better" way?
> 
> Blaine

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to