Yeah, that should do it. Again, it might be the case that I'm trying to solve
something that doesn't need to be solved. Since it seemed there was an extra
hole I could close, suspenders and belt so to speak, using log4net and
redefining OFF to the value of INFO, I was wondering whether the same thing
could be done with log4j.
Thanks,
Nick
> Subject: Re: redefining existing levels?
> From: ralph.go...@dslextreme.com
> Date: Wed, 26 Aug 2015 09:31:19 -0700
> To: log4j-user@logging.apache.org
>
> Can’t you just put a comment in the config file that states the minimum
> logging level is info and that it is not to be changed under any
> circumstances?
>
> Ralph
>
> > On Aug 26, 2015, at 9:27 AM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > Maybe what I'm trying to do is not that useful. However, I'm guessing the
> > person mucking around with things would probably feel uncomfortable
> > deleting entries in the config. If they are familiar with log4j they might
> > feel comfortable setting the level if they think they should be turning
> > things off.
> >
> > Basically, we have what we'll call "always on" or "24x7" logging. This is
> > about always having INFO and more critical turned on. I'm just looking for
> > ways to help enforce that.
> >
> > Thanks,
> > Nick
> >
> >> Date: Wed, 26 Aug 2015 09:24:07 -0700
> >> Subject: Re: redefining existing levels?
> >> From: garydgreg...@gmail.com
> >> To: log4j-user@logging.apache.org
> >>
> >> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>
> >>> I guess the main use case we're trying to solve is someone, maybe some
> >>> admin or maybe a developer asking the admin, thinking they should turn
> >>> logging off and thus sets the level to "OFF". We always want INFO and
> >>> more
> >>> critical levels to be on no matter what.
> >>>
> >>
> >> But if a user gets in a config file and sets the root level to off, how can
> >> you stop him or her from removing your filters and custom levels?
> >>
> >> Gary
> >>
> >>>
> >>> Thanks,
> >>> Nick
> >>>
> >>>> Subject: Re: redefining existing levels?
> >>>> To: log4j-user@logging.apache.org
> >>>> From: x...@dds.nl
> >>>> Date: Wed, 26 Aug 2015 17:55:23 +0200
> >>>>
> >>>> I think it is still unclear what you mean by "below". Normally I would
> >>>> consider "trace" to be at the low end and "fatal" to be at the high end,
> >>>> but I don't think there is a low and high in Log4J. When you say "below"
> >>>> I take it you mean DEBUG and TRACE, but the only thing that makes sense
> >>>> to me is to keep INFO, ERROR and FATAL on.
> >>>>
> >>>> Regards, Bart.
> >>>>
> >>>>
> >>>>
> >>>> Op 26-8-2015 om 3:46 schreef Nicholas Duane:
> >>>>> Yes and no. The user might know how to turn on/off logging, but they
> >>> might not understand what the enterprise is wanting to do. We would like
> >>> to make it hard, if not impossible, to turn off logging of INFO and below
> >>> (or above for .NET) events. So even if something thinks they should turn
> >>> off logging and sets the level to "OFF" we still want INFO and below to be
> >>> logged.
> >>>>>
> >>>>> Thanks,
> >>>>> Nick
> >>>>>
> >>>>>> Subject: Re: redefining existing levels?
> >>>>>> From: remko.po...@gmail.com
> >>>>>> Date: Wed, 26 Aug 2015 09:25:09 +0900
> >>>>>> To: log4j-user@logging.apache.org
> >>>>>>
> >>>>>> Could you explain a bit more about your use case before we zoom in on
> >>> a specific solution?
> >>>>>>
> >>>>>> I'd like to understand better what you mean by [if someone sets the
> >>> level to "OFF"]?
> >>>>>> What is the scenario? Someone logs into the server and modifies the
> >>> configuration and makes a mistake? Or is this a client distributed to your
> >>> users' PCs and they may modify the configuration?
> >>>>>>
> >>>>>> It sounds like you are trying to protect against human error; is that
> >>> the case?
> >>>>>>
> >>>>>> Sent from my iPhone
> >>>>>>
> >>>>>>> On 2015/08/26, at 8:37, Nicholas Duane <nic...@msn.com> wrote:
> >>>>>>>
> >>>>>>> No. Redefining existing levels is to help ensure we have "24x7"
> >>> logging always on. So even if someone sets the level to "OFF" we still
> >>> get
> >>> INFO and above. Basically we'll have levels higher (or lower based on
> >>> what
> >>> platform we're talking about) than INFO OFF by default and only turn them
> >>> on when needed.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Nick
> >>>>>>>
> >>>>>>>> Date: Wed, 26 Aug 2015 08:33:34 +0900
> >>>>>>>> Subject: Re: redefining existing levels?
> >>>>>>>> From: remko.po...@gmail.com
> >>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>
> >>>>>>>> Is redefining levels a way to work around the issue you had with
> >>> the range
> >>>>>>>> check?
> >>>>>>>> I've replied to your range check question with a link to an example
> >>> config.
> >>>>>>>>
> >>>>>>>> On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory <
> >>> garydgreg...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Well, let's all work together to get you up and running. Hopefully
> >>> we'll
> >>>>>>>>> get other devs to keep chiming in.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Gary
> >>>>>>>>>
> >>>>>>>>>> On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane <nic...@msn.com>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I will get to that. However, I assume that works as that's
> >>> documented
> >>>>>>>>>> pretty well. So I'm looking at the other things which may or may
> >>> not
> >>>>>>>>> work
> >>>>>>>>>> as I have to find out what blocking issues we're going to run
> >>> into.
> >>>>>>>>>> Redefining existing levels is one. I sent the other email
> >>> regarding
> >>>>>>>>> range
> >>>>>>>>>> level filter as we also need that to work. It works in .NET. So
> >>> far
> >>>>>>>>> it's
> >>>>>>>>>> looking like I'll need to write my own filter for log4j2 in order
> >>> to get
> >>>>>>>>>> range level filtering working.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Nick
> >>>>>>>>>>
> >>>>>>>>>>> Date: Tue, 25 Aug 2015 15:54:08 -0700
> >>>>>>>>>>> Subject: Re: redefining existing levels?
> >>>>>>>>>>> From: garydgreg...@gmail.com
> >>>>>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>> Ah, well, let's start with the documented stuff we know should
> >>> work ;-)
> >>>>>>>>>>>
> >>>>>>>>>>> Gary
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane <nic...@msn.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>> Thanks. I assumed my 'BUSINESS' level is working using the
> >>>>>>>>>> <CustomLevel>,
> >>>>>>>>>>>> though I haven't tried it yet as I was trying to validate
> >>> redefining
> >>>>>>>>>>>> existing level.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Nick
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Date: Tue, 25 Aug 2015 14:32:01 -0700
> >>>>>>>>>>>>> Subject: Re: redefining existing levels?
> >>>>>>>>>>>>> From: garydgreg...@gmail.com
> >>>>>>>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nick,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Your BUSINESS level should be configurable per
> >>>>>>>>>
> >>> https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration
> >>>>>>>>>>>>> I can't look into the rest ATM.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Gary
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane <
> >>> nic...@msn.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>> I guess I should have mentioned, though it's probably obvious,
> >>>>>>>>>> that I'm
> >>>>>>>>>>>>>> only interested in a configuration based solution. I'm not
> >>>>>>>>> looking
> >>>>>>>>>>>> for a
> >>>>>>>>>>>>>> code solution.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From: nic...@msn.com
> >>>>>>>>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>>>>>>> Subject: RE: redefining existing levels?
> >>>>>>>>>>>>>> Date: Tue, 25 Aug 2015 16:05:47 -0400
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for the reply. I've seen that documentation and it
> >>>>>>>>> appears
> >>>>>>>>>> to
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>> geared toward defining (NEW) custom levels. It doesn't
> >>> mention
> >>>>>>>>>>>> anything
> >>>>>>>>>>>>>> about redefining existing log4j2 levels. I also tried it and
> >>> so
> >>>>>>>>>> far
> >>>>>>>>>>>> in my
> >>>>>>>>>>>>>> testing it doesn't seem to work. Below is a snippet of my
> >>>>>>>>>> config. By
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>> way, you'll see that I am currently trying the <CustomLevel>
> >>> and
> >>>>>>>>>>>> <level>.
> >>>>>>>>>>>>>> At first I had just tried <CustomLevel> but it didn't appear
> >>> to
> >>>>>>>>>> work
> >>>>>>>>>>>> so I
> >>>>>>>>>>>>>> thought I would put the same elements I have in my .NET config
> >>>>>>>>>> which
> >>>>>>>>>>>> work.
> >>>>>>>>>>>>>> Unfortunately it still doesn't work.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> <level>
> >>>>>>>>>>>>>> <name value="OFF"/>
> >>>>>>>>>>>>>> <value value="500"/>
> >>>>>>>>>>>>>> </level>
> >>>>>>>>>>>>>> <CustomLevels>
> >>>>>>>>>>>>>> <CustomLevel name="OFF" intLevel="500"/>
> >>>>>>>>>>>>>> </CustomLevels>
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> .
> >>>>>>>>>>>>>> <Loggers>
> >>>>>>>>>>>>>> <Logger name="HelloWorld" level="OFF">
> >>>>>>>>>>>>>> <AppenderRef ref="debug"/>
> >>>>>>>>>>>>>> </Logger>
> >>>>>>>>>>>>>> <Root>
> >>>>>>>>>>>>>> </Root>
> >>>>>>>>>>>>>> </Loggers>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I then set my logger level to "OFF" and didn't see any debug
> >>>>>>>>> events
> >>>>>>>>>>>> show
> >>>>>>>>>>>>>> up. If I set the level to "DEBUG" they show up in the log.
> >>> The
> >>>>>>>>>> docs
> >>>>>>>>>>>> say
> >>>>>>>>>>>>>> that DEBUG is set to 500, so me setting OFF to 500 and then
> >>>>>>>>>> setting the
> >>>>>>>>>>>>>> level on my logger to OFF should have allowed the debug
> >>> events to
> >>>>>>>>>> flow
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> the log file, correct?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Date: Tue, 25 Aug 2015 12:50:32 -0700
> >>>>>>>>>>>>>>> Subject: Re: redefining existing levels?
> >>>>>>>>>>>>>>> From: garydgreg...@gmail.com
> >>>>>>>>>>>>>>> To: log4j-user@logging.apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Nicholas,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Yes, please see
> >>>>>>>>> https://logging.apache.org/log4j/2.x/manual/customloglevels.html
> >>>>>>>>>>>>>>> If the documentation can be improved, please let us know how.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Gary
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Aug 25, 2015 at 12:42 PM, Nicholas Duane <
> >>>>>>>>> nic...@msn.com
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> Can existing log4j2 levels be redefined? I'm able to do
> >>> this
> >>>>>>>>>> in
> >>>>>>>>>>>>>> log4net.
> >>>>>>>>>>>>>>>> I have yet to see any documentation telling me that I can do
> >>>>>>>>>> it,
> >>>>>>>>>>>>>> however,
> >>>>>>>>>>>>>>>> there was none telling me I could do it for .NET either. I
> >>>>>>>>>> just
> >>>>>>>>>>>>>> happen to
> >>>>>>>>>>>>>>>> stumble upon a post which eluded to it. Here is what I've
> >>>>>>>>>> done in
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> log4net config file:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> <configuration>
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> <log4net>
> >>>>>>>>>>>>>>>> <level>
> >>>>>>>>>>>>>>>> <name value="Off"/>
> >>>>>>>>>>>>>>>> <value value="40000"/>
> >>>>>>>>>>>>>>>> <level>
> >>>>>>>>>>>>>>>> <level>
> >>>>>>>>>>>>>>>> <name value="Business"/>
> >>>>>>>>>>>>>>>> <value value="130000"/>
> >>>>>>>>>>>>>>>> <level>
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> </log4net>
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>> </configuration>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As you can see I created my own 'Business' level. I also
> >>>>>>>>>> redefined
> >>>>>>>>>>>>>> Off to
> >>>>>>>>>>>>>>>> 40000 which happens to be the INFO level. This makes it
> >>> such
> >>>>>>>>>> that
> >>>>>>>>>>>> if
> >>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>> set the level to Off they will still receive INFO and higher
> >>>>>>>>>> level
> >>>>>>>>>>>>>> events.
> >>>>>>>>>>>>>>>> Can the same thing be done in log4j2?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>> Nick
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
> >>>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> E-Mail: garydgreg...@gmail.com | ggreg...@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
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
