Re: redefining existing levels?

2015-08-27 Thread Mikael Ståldal
If some of the logging is business critical, perhaps you should put it in a
separate logging context and don't let your users reconfigure that context.
Or not use Log4j at all for the business critical logging.

On Wed, Aug 26, 2015 at 3:46 AM, Nicholas Duane  wrote:

> 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  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  >
> > >> 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 
> 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 
> > >>> wrote:
> > >>>>>
> > >>>>>> Thanks.  I assumed my 'BUSINESS' level is working using the
> > >>>> ,
> > >>>>>> though I haven't tried it yet as I was trying to validate
> redefining
> > >>>>>> existing level.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Nick
> > >&

Re: redefining existing levels?

2015-08-26 Thread Remko Popma
I am glad I asked these questions.
In my opinion, you cannot protect people from messing up your configuration
by providing them with some configuration, for the simple reason that they
can modify your changes.

I am also with Ralph in that I am not a fan of a minimum log level that
would ignore what the user configured. That is just confusing.

If you really want to take away the option for your users to modify the
logging configuration, your only option may be to programmatically
configure Log4j. There is work in progress
<https://issues.apache.org/jira/browse/LOG4J2-952> for this. Of course the
knife cuts both ways: this also means that if you need to support them, you
cannot ask them to increase the log level to TRACE to help you diagnose the
issue... My advice would be to trust that your users are smart enough not
to mess it up. :-)


On Thu, Aug 27, 2015 at 1:44 AM, Gary Gregory 
wrote:

> On Wed, Aug 26, 2015 at 9:42 AM, Nicholas Duane  wrote:
>
> > No, I don't know what "monitorInterval" is.
>
>
> Please see
>
> https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration
>
> Gary
>
>
> > Right now in log4net, which is where I'm redefining OFF, we have the
> > log4net configuration in the application configuration file.  So it for
> > instance it's a web application, touching the log4net configuration will
> > restart the application domain.
> >
> > Thanks,
> > Nick
> >
> > > Date: Wed, 26 Aug 2015 09:32:15 -0700
> > > Subject: Re: redefining existing levels?
> > > From: garydgreg...@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane 
> 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.
> > > >
> > >
> > > Does this mean you use Log4j with the "monitorInterval" Confuguration
> > > attribute? Or can this user also restart the application by hand for
> the
> > > new logging configuration to take effect?
> > >
> > > Gary
> > >
> > > >
> > > > 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 
> > 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,
> > > > > > &g

Re: redefining existing levels?

2015-08-26 Thread Gary Gregory
On Wed, Aug 26, 2015 at 9:42 AM, Nicholas Duane  wrote:

> No, I don't know what "monitorInterval" is.


Please see
https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

Gary


> Right now in log4net, which is where I'm redefining OFF, we have the
> log4net configuration in the application configuration file.  So it for
> instance it's a web application, touching the log4net configuration will
> restart the application domain.
>
> Thanks,
> Nick
>
> > Date: Wed, 26 Aug 2015 09:32:15 -0700
> > Subject: Re: redefining existing levels?
> > From: garydgreg...@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane  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.
> > >
> >
> > Does this mean you use Log4j with the "monitorInterval" Confuguration
> > attribute? Or can this user also restart the application by hand for the
> > new logging configuration to take effect?
> >
> > Gary
> >
> > >
> > > 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 
> 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 existi

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
No, I don't know what "monitorInterval" is.  Right now in log4net, which is 
where I'm redefining OFF, we have the log4net configuration in the application 
configuration file.  So it for instance it's a web application, touching the 
log4net configuration will restart the application domain.
 
Thanks,
Nick
 
> Date: Wed, 26 Aug 2015 09:32:15 -0700
> Subject: Re: redefining existing levels?
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane  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.
> >
> 
> Does this mean you use Log4j with the "monitorInterval" Confuguration
> attribute? Or can this user also restart the application by hand for the
> new logging configuration to take effect?
> 
> Gary
> 
> >
> > 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  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
>

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
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  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  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 a

Re: redefining existing levels?

2015-08-26 Thread Gary Gregory
On Wed, Aug 26, 2015 at 9:31 AM, Ralph Goers 
wrote:

> 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?
>

That seems to obvious! :-)

Another interesting but complex alternative would be to use a custom XML
Schema to validate the XML configuration file. If the validation fails,
we'd need to make sure we do not process the file any further. XML Schemas
are not easy to write though but can be automatically generated by some
tools.


Gary


> Ralph
>
> > On Aug 26, 2015, at 9:27 AM, Nicholas Duane  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  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
> >>>>&g

Re: redefining existing levels?

2015-08-26 Thread Gary Gregory
On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane  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.
>

Does this mean you use Log4j with the "monitorInterval" Confuguration
attribute? Or can this user also restart the application by hand for the
new logging configuration to take effect?

Gary

>
> 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  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  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

Re: redefining existing levels?

2015-08-26 Thread Ralph Goers
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  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  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  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?
>>>>>&g

Re: redefining existing levels?

2015-08-26 Thread Ralph Goers
Well, I suppose we could add a minimum logging level system property and if 
someone tries to set the level lower than that then the minimum level gets used 
instead.  But I’m not really crazy about that as it could cause all kinds of 
“unexpected” consequences when processing the configuration.

It seems to me that the real issue is that people have access to your 
production machines who probably shouldn’t.

Ralph

> On Aug 26, 2015, at 9:24 AM, Gary Gregory  wrote:
> 
> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane  <mailto: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  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.
&g

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
I should have add:
 
"ways to enforce that via configuration".  We don't want to do it via code and 
we don't want to have to rely on some of our code being run at startup.
 
Thanks,
Nick
 
From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Wed, 26 Aug 2015 12:27:16 -0400




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  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  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
> > > >>>>
> 

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
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  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  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

Re: redefining existing levels?

2015-08-26 Thread Gary Gregory
On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane  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  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 
> 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
> > >>>>>>

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
I'm one of the developers in the framework team.  We're working on a logging 
framework.  Let's say the enterprise direction is to always capture INFO and 
more critical.  If someone, who happens to have access to the server(s), does 
something they think they should do but in fact they shouldn't be doing, like 
turning logging to "OFF", we would like INFO and more critical levels to still 
be flowing.
 
Thanks,
Nick
 
> Subject: Re: redefining existing levels?
> To: log4j-user@logging.apache.org
> From: x...@dds.nl
> Date: Wed, 26 Aug 2015 17:56:10 +0200
> 
> Op 26-8-2015 om 5:43 schreef Gary Gregory:
> > On Tue, Aug 25, 2015 at 7:59 PM, Remko Popma  wrote:
> >
> >> How are users currently able to set the log level to OFF? Do they modify
> >> the config?
> >>
> > Right, isn't the only way to enforce this is to override the config file
> > programatically?
> >
> > Gary
> 
> And are you not the one who allows your users this functionality? Or do 
> they get to set a dedicated config script? Can't your user actions 
> simply be filtered or disallowed, or not even presented?.
> 
> Or are your users programmers?.
> 
> 
> >> Sent from my iPhone
> >>
> >>> On 2015/08/26, at 11:35, Nicholas Duane  wrote:
> >>>
> >>> It just dawned on me that my solution of redefining OFF to the INFO
> >> level only addresses the case of someone setting the level to OFF.  Someone
> >> could set the level to ERROR.
> >>> As I mentioned, what I'm trying to do is enforce, via configuration
> >> only, not being able to turn of logging of INFO and below levels.
> >>> Thanks,Nick
> >>>
> >>>  Original message 
> >>> From: Nicholas Duane 
> >>> Date: 08/25/2015  7:46 PM  (GMT-07:00)
> >>> To: Log4J Users List 
> >>> Subject: RE: redefining existing levels?
> >>>
> >>> 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  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  >>>>>> wrote:
> >>>>>>
> >>>>>>> Well, let's all work together to ge

RE: redefining existing levels?

2015-08-26 Thread Nicholas Duane
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.
 
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  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 
> >>>> 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  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:

Re: redefining existing levels?

2015-08-26 Thread Xen

Op 26-8-2015 om 5:43 schreef Gary Gregory:

On Tue, Aug 25, 2015 at 7:59 PM, Remko Popma  wrote:


How are users currently able to set the log level to OFF? Do they modify
the config?


Right, isn't the only way to enforce this is to override the config file
programatically?

Gary


And are you not the one who allows your users this functionality? Or do 
they get to set a dedicated config script? Can't your user actions 
simply be filtered or disallowed, or not even presented?.


Or are your users programmers?.



Sent from my iPhone


On 2015/08/26, at 11:35, Nicholas Duane  wrote:

It just dawned on me that my solution of redefining OFF to the INFO

level only addresses the case of someone setting the level to OFF.  Someone
could set the level to ERROR.

As I mentioned, what I'm trying to do is enforce, via configuration

only, not being able to turn of logging of INFO and below levels.

Thanks,Nick

 Original message 
From: Nicholas Duane 
Date: 08/25/2015  7:46 PM  (GMT-07:00)
To: Log4J Users List 
Subject: RE: redefining existing levels?

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  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 
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 

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 

wrote:

Thanks.  I assumed my 'BUSINESS' level is working using the

,

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 

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 

Re: redefining existing levels?

2015-08-26 Thread Xen
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  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 
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  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 

wrote:

Thanks.  I assumed my 'BUSINESS' level is working using the

,

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 

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  and

.

At first I had just tried  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.

.
.
.

   
   


   

.
.
.

   
  
   
   
   


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 s

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
On Tue, Aug 25, 2015 at 7:59 PM, Remko Popma  wrote:

> How are users currently able to set the log level to OFF? Do they modify
> the config?
>

Right, isn't the only way to enforce this is to override the config file
programatically?

Gary



>
> Sent from my iPhone
>
> > On 2015/08/26, at 11:35, Nicholas Duane  wrote:
> >
> > It just dawned on me that my solution of redefining OFF to the INFO
> level only addresses the case of someone setting the level to OFF.  Someone
> could set the level to ERROR.
> > As I mentioned, what I'm trying to do is enforce, via configuration
> only, not being able to turn of logging of INFO and below levels.
> > Thanks,Nick
> >
> >  Original message 
> > From: Nicholas Duane 
> > Date: 08/25/2015  7:46 PM  (GMT-07:00)
> > To: Log4J Users List 
> > Subject: RE: redefining existing levels?
> >
> > 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  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  >
> >>>> 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 
> 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

Re: redefining existing levels?

2015-08-25 Thread Remko Popma
How are users currently able to set the log level to OFF? Do they modify the 
config?

Sent from my iPhone

> On 2015/08/26, at 11:35, Nicholas Duane  wrote:
> 
> It just dawned on me that my solution of redefining OFF to the INFO level 
> only addresses the case of someone setting the level to OFF.  Someone could 
> set the level to ERROR.
> As I mentioned, what I'm trying to do is enforce, via configuration only, not 
> being able to turn of logging of INFO and below levels.
> Thanks,Nick
> 
>  Original message 
> From: Nicholas Duane 
> Date: 08/25/2015  7:46 PM  (GMT-07:00)
> To: Log4J Users List 
> Subject: RE: redefining existing levels?
> 
> 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  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 
>>>> 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  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 
>>>>> wrote:
>>>>>>> 
>>>>>>>> Thanks.  I assumed my 'BUSINESS' 

RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
It just dawned on me that my solution of redefining OFF to the INFO level only 
addresses the case of someone setting the level to OFF.  Someone could set the 
level to ERROR.
As I mentioned, what I'm trying to do is enforce, via configuration only, not 
being able to turn of logging of INFO and below levels.
Thanks,Nick

 Original message 
From: Nicholas Duane 
Date: 08/25/2015  7:46 PM  (GMT-07:00)
To: Log4J Users List 
Subject: RE: redefining existing levels?

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  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 
> >> 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  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 
> >>> wrote:
> >>>>>
> >>>>>> Thanks.  I assumed my 'BUSINESS' level is working using the
> >>>> ,
> >>>>>> 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.co

RE: redefining existing levels?

2015-08-25 Thread 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  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 
> >> 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  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 
> >>> wrote:
> >>>>> 
> >>>>>> Thanks.  I assumed my 'BUSINESS' level is working using the
> >>>> ,
> >>>>>> 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 

Re: redefining existing levels?

2015-08-25 Thread Remko Popma
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  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 
>> 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  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 
>>> wrote:
>>>>> 
>>>>>> Thanks.  I assumed my 'BUSINESS' level is working using the
>>>> ,
>>>>>> 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 
>>>> 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
>>>>>>>> 

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
I added a test
called org.apache.logging.log4j.core.CustomLevelsOverrideTest in Git master.

It shows that overriding a standard level's int value does not work.

Gary

On Tue, Aug 25, 2015 at 4:37 PM, Nicholas Duane  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 
> > 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 
> 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 
> > > wrote:
> > > > >
> > > > > > Thanks.  I assumed my 'BUSINESS' level is working using the
> > > > ,
> > > > > > 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 exist

RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
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 
> 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  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 
> > wrote:
> > > >
> > > > > Thanks.  I assumed my 'BUSINESS' level is working using the
> > > ,
> > > > > 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 
> > > 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
>

Re: redefining existing levels?

2015-08-25 Thread Remko Popma
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 
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  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 
> wrote:
> > >
> > > > Thanks.  I assumed my 'BUSINESS' level is working using the
> > ,
> > > > 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 
> > 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  and
> > > > .
> > > > > > At first I had just tried  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.
> > > > > >
> > > > > > .
> > > > > > .
> > > > > > .
> > > > > > 
> > > > > >
> > > > > >
> > > > > > 
> > > > > > 
> > > > > >
> > > > > > 
> > > > > > .
> > > > > > .
> > > > > > .
> > > > > > 
> > > > > &

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
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  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  wrote:
> >
> > > Thanks.  I assumed my 'BUSINESS' level is working using the
> ,
> > > 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 
> 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  and
> > > .
> > > > > At first I had just tried  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.
> > > > >
> > > > > .
> > > > > .
> > > > > .
> > > > > 
> > > > >
> > > > >
> > > > > 
> > > > > 
> > > > >
> > > > > 
> > > > > .
> > > > > .
> > > > > .
> > > > > 
> > > > >
> > > > >   
> > > > >
> > > > >
> > > > >
> > > > > 
> > > > >
> > > > > I then set my logger level to "OFF" and didn't see any debug events
> > > show
> > > > > up.  If I set the level to &qu

RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
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  wrote:
> 
> > Thanks.  I assumed my 'BUSINESS' level is working using the ,
> > 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  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  and
> > .
> > > > At first I had just tried  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.
> > > >
> > > > .
> > > > .
> > > > .
> > > > 
> > > >
> > > >
> > > > 
> > > > 
> > > >
> > > > 
> > > > .
> > > > .
> > > > .
> > > > 
> > > >
> > > >   
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > 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 
> > wrote:
> > > > >
> > > &g

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
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  wrote:

> Thanks.  I assumed my 'BUSINESS' level is working using the ,
> 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  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  and
> .
> > > At first I had just tried  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.
> > >
> > > .
> > > .
> > > .
> > > 
> > >
> > >
> > > 
> > > 
> > >
> > > 
> > > .
> > > .
> > > .
> > > 
> > >
> > >   
> > >
> > >
> > >
> > > 
> > >
> > > 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 
> 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:
> > > > >
> > > > > 
> > > > >.
> > > > >.
> > > > >.
> > > > >
> > > > >   
> > > > >  
> > > > >  
> > > > >   
> > > > >   
> > > > >  
> > > > >  
> > > > >   
> > > > >   .
> > > > >   .
> > > > >   .
> > > > >
> > > > >.
> > > > >.
> > > > >.
> > > > > 
> > > > >
> > > > > As you can see I created my own &

RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
Thanks.  I assumed my 'BUSINESS' level is working using the , 
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  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  and .
> > At first I had just tried  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.
> >
> > .
> > .
> > .
> > 
> >
> >
> > 
> > 
> >
> > 
> > .
> > .
> > .
> > 
> >
> >   
> >
> >
> >
> > 
> >
> > 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  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:
> > > >
> > > > 
> > > >.
> > > >.
> > > >.
> > > >
> > > >   
> > > >  
> > > >  
> > > >   
> > > >   
> > > >  
> > > >  
> > > >   
> > > >   .
> > > >   .
> > > >   .
> > > >
> > > >.
> > > >.
> > > >.
> > > > 
> > > >
> > > > As you can see I created my own 'Business' level.  I also redefined
> > Off to
> > > > 4 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
  

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
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  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  and .
> At first I had just tried  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.
>
> .
> .
> .
> 
>
>
> 
> 
>
> 
> .
> .
> .
> 
>
>   
>
>
>
> 
>
> 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  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:
> > >
> > > 
> > >.
> > >.
> > >.
> > >
> > >   
> > >  
> > >  
> > >   
> > >   
> > >  
> > >  
> > >   
> > >   .
> > >   .
> > >   .
> > >
> > >.
> > >.
> > >.
> > > 
> > >
> > > As you can see I created my own 'Business' level.  I also redefined
> Off to
> > > 4 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


RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
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  and .  At first I had just 
tried  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.

.
.
.

   
   


   

.
.
.

   
  
   
   
   


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  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:
> >
> > 
> >.
> >.
> >.
> >
> >   
> >  
> >  
> >   
> >   
> >  
> >  
> >   
> >   .
> >   .
> >   .
> >
> >.
> >.
> >.
> > 
> >
> > As you can see I created my own 'Business' level.  I also redefined Off to
> > 4 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

  

RE: redefining existing levels?

2015-08-25 Thread Nicholas Duane
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  and .  At first I had just 
tried  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.

.
.
.

   
   


   

.
.
.

   
  
   
   
   


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  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:
> >
> > 
> >.
> >.
> >.
> >
> >   
> >  
> >  
> >   
> >   
> >  
> >  
> >   
> >   .
> >   .
> >   .
> >
> >.
> >.
> >.
> > 
> >
> > As you can see I created my own 'Business' level.  I also redefined Off to
> > 4 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
  

Re: redefining existing levels?

2015-08-25 Thread Gary Gregory
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  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:
>
> 
>.
>.
>.
>
>   
>  
>  
>   
>   
>  
>  
>   
>   .
>   .
>   .
>
>.
>.
>.
> 
>
> As you can see I created my own 'Business' level.  I also redefined Off to
> 4 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory


redefining existing levels?

2015-08-25 Thread Nicholas Duane
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:


   .
   .
   .
   
  
 
 
  
  
 
 
  
  .
  .
  .
   
   .
   .
   .


As you can see I created my own 'Business' level.  I also redefined Off to 
4 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