logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blaine Bergeson (bbergeson)" <bberge...@micron.com>
Subject Re: Getting Started
Date Sat, 17 Jan 2015 08:07:54 GMT
Most of our apps are desktop client applications that need to be able to run stand alone are
used to control internally produced equipment and are never exposed to external customers,
i.e. They are tools written by Engineers for Engineers. 

Thanks for the ideas and suggestions. After weighing all the options so far I would still
say that staying with one simple configuration file and then just calling the 4 lines of code
in the application to change the level is easy and fairly straightforward. I am not really
in favor of the xml configuration being changed after the app has been deployed.  In fact
the configuration file will be embedded in the jar file so the customer will never see it.
I also think swapping between multiple files is more complex than it needs to be. I like leaving
the control of the overall  log level in the app which is where the change in mode originates


Sent from my iPhone

> On Jan 16, 2015, at 9:51 PM, Remko Popma <remko.popma@gmail.com> wrote:
> I don't think I understand your use case. Is this a web application,
> client-server, or a stand-alone app?
> FYI, the easiest and safest way to accomplish on-the-fly reconfiguration
> may be to set a monitoringInterval
> <http://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration>
> in
> your configuration file. Then, if the configuration file is modified, Log4j
> will automatically reload the configuration and reconfigure.
> Users can manually edit the configuration file, or if this needs to be
> automated, I can imaging preparing a number of configuration files for the
> logging profiles you require, and swap the configuration file in your
> program.
> On Sat, Jan 17, 2015 at 9:41 AM, Blaine Bergeson (bbergeson) <
> bbergeson@micron.com> wrote:
>> Remko,
>> Thanks for your feedback. Actually I do want to change the log level by
>> user mode because our users are internal engineers and will look at the log
>> files. We also don't want excessive logging when unnecessary so by changing
>> modes in the fly we can bump up the logging to get more information. Many
>> tools do this, in fact even NetBeans does this through commandline switches.
>> I have learned some additional things which may be bugs or just how it is
>> suppose to work or I am missing something. I will post them on a new thread.
>> Blaine
>> Sent from my iPhone
>>> On Jan 15, 2015, at 5:37 PM, Remko Popma <remko.popma@gmail.com> wrote:
>>> 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)" <
>> bbergeson@micron.com> 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: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message