You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2018/09/15 21:07:22 UTC
Conditional appender enablement
Hi All:
At work, we have an installer program that installs one of five log4j
configs depending on what the user selects in a UI. Each of these 5 configs
causes log events to end up in different kinds of SQL and NoSQL databases,
you pick one when you install. The installer does a brute force search and
replace in the log4j file to replace markers with things like database IP
addresses and port numbers. So far so simple and good.
The next iteration of the installer provides an additional choice to log to
a file or not, in addition of one of the 5 databases.
Option 1?
In order to avoid having 5x2 preset config files in the installer, I'd like
to add the file config to each of the existing 5 configurations and have
the file appender enabled or not based on a boolean flag that the installer
can implement as part of its search and replace. You'd end up with:
<AppenderRef ref="foo" enabled="true|false" />
<AppenderFoo enabled="true|false" />
If an appender is disabled it does not end up in the Log4j object tree at
all. It is like it never existed in the config file.
Option 2?
Add a second log4j2.xml, say log4j2-rollingfile.xml config file and have
Log4j combine it with the other log4j.xml on the class path. How?
Other options?
Thank you,
Gary
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Sep 16, 2018 at 11:19 AM Matt Sicker <bo...@gmail.com> wrote:
> If I recall correctly, the NullAppender is there mainly to avoid
> ClassLoader errors during shutdown in certain scenarios (e.g., shutdown
> before any appenders were initialized, so the class might not be loaded
> yet).
>
Well, it's quite handy in this use case :-) in fact, without it, we would
log an error to the status logger.
Gary
> On Sun, 16 Sep 2018 at 12:03, Gary Gregory <ga...@gmail.com> wrote:
>
> > On Sat, Sep 15, 2018 at 5:22 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Sat, Sep 15, 2018 at 5:16 PM Gary Gregory <ga...@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <ga...@gmail.com>
> > >> wrote:
> > >>
> > >>> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <
> > ralph.goers@dslextreme.com>
> > >>> wrote:
> > >>>
> > >>>> If you don’t want to log anything then enable a noop appender that
> > just
> > >>>> returns without doing anything
> > >>>>
> > >>>
> > >>> Oh, I see we already have a NullAppender...
> > >>>
> > >>
> > >> So I can do:
> > >>
> > >> <ScriptAppenderSelector name="SelectIt">
> > >> <Script language="JavaScript"><![CDATA[
> > >> ##SPECIAL_THING##]]>
> > >> </Script>
> > >> <AppenderSet>
> > >> <RollingFileAppender name="MyAppender" ... />
> > >> <Null/>
> > >> </AppenderSet>
> > >> </ScriptAppenderSelector>
> > >>
> > >> Not quite as simple as:
> > >>
> > >> <RollingFileAppender name="MyAppender" enable="##SPECIAL_THING##" ...
> />
> > >>
> > >> I often times have to walk our users through some configs so option 2
> is
> > >> simpler for them and less error prone... but option 1 will work for
> > now...
> > >>
> > >
> > > The not great thing here is that for each appender I want to be able to
> > > toggle, I have to repeat this pattern...
> > >
> >
> > I have something working, if ponderously, using the
> ScriptAppenderSelector.
> > After looking at all the configs I had to update, it seems that
> supporting
> > an "enabled" attribute would be much cleaners.
> >
> > Gary
> >
> >
> > > Gary
> > >
> > >>
> > >> Gary
> > >>
> > >>
> > >>>
> > >>> Gary
> > >>>
> > >>>
> > >>>>
> > >>>> Sent from my iPhone
> > >>>>
> > >>>> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <
> garydgregory@gmail.com>
> > >>>> wrote:
> > >>>> >
> > >>>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <
> > >>>> ralph.goers@dslextreme.com>
> > >>>> > wrote:
> > >>>> >
> > >>>> >> We have an appended selector for this. Why not us it?
> > >>>> >>
> > >>>> >
> > >>>> > Hi,
> > >>>> >
> > >>>> > Because:
> > >>>> > - Conceptually, I am not selecting an appender out of a set, I
> want
> > >>>> the one
> > >>>> > appender enabled or disabled.
> > >>>> > - In practice, using a ScriptAppenderSelector with a single
> Appender
> > >>>> means
> > >>>> > my script would have to 'select' a non-existing appender when the
> > >>>> script
> > >>>> > evaluates to false, which would work BUT would emit an ERROR log
> > >>>> event to
> > >>>> > the status logger like "No node named DISABLE_ME in
> > >>>> > NameOfScriptAppenderSelector". This would be a normal
> configuration,
> > >>>> so an
> > >>>> > ERROR would be very bad for our users. Changing the level of event
> > >>>> would
> > >>>> > not help, unless it was buried at the DEBUG level, which is not
> good
> > >>>> for
> > >>>> > the current use cases.
> > >>>> > - Alternatively, we could have add a NoOpAppender which I would
> then
> > >>>> select
> > >>>> > when I want the file appender disabled. This would imply accepting
> > the
> > >>>> > added costs, no matter how minor in memory and speed.
> > >>>> >
> > >>>> > Thoughts?
> > >>>> >
> > >>>> > Gary
> > >>>> >
> > >>>> >
> > >>>> >>
> > >>>> >> Sent from my iPhone
> > >>>> >>
> > >>>> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <
> > garydgregory@gmail.com>
> > >>>> >> wrote:
> > >>>> >>>
> > >>>> >>> Hi All:
> > >>>> >>>
> > >>>> >>> At work, we have an installer program that installs one of five
> > >>>> log4j
> > >>>> >>> configs depending on what the user selects in a UI. Each of
> these
> > 5
> > >>>> >> configs
> > >>>> >>> causes log events to end up in different kinds of SQL and NoSQL
> > >>>> >> databases,
> > >>>> >>> you pick one when you install. The installer does a brute force
> > >>>> search
> > >>>> >> and
> > >>>> >>> replace in the log4j file to replace markers with things like
> > >>>> database IP
> > >>>> >>> addresses and port numbers. So far so simple and good.
> > >>>> >>>
> > >>>> >>> The next iteration of the installer provides an additional
> choice
> > >>>> to log
> > >>>> >> to
> > >>>> >>> a file or not, in addition of one of the 5 databases.
> > >>>> >>>
> > >>>> >>> Option 1?
> > >>>> >>> In order to avoid having 5x2 preset config files in the
> installer,
> > >>>> I'd
> > >>>> >> like
> > >>>> >>> to add the file config to each of the existing 5 configurations
> > and
> > >>>> have
> > >>>> >>> the file appender enabled or not based on a boolean flag that
> the
> > >>>> >> installer
> > >>>> >>> can implement as part of its search and replace. You'd end up
> > with:
> > >>>> >>>
> > >>>> >>> <AppenderRef ref="foo" enabled="true|false" />
> > >>>> >>> <AppenderFoo enabled="true|false" />
> > >>>> >>>
> > >>>> >>> If an appender is disabled it does not end up in the Log4j
> object
> > >>>> tree at
> > >>>> >>> all. It is like it never existed in the config file.
> > >>>> >>>
> > >>>> >>> Option 2?
> > >>>> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file
> > and
> > >>>> have
> > >>>> >>> Log4j combine it with the other log4j.xml on the class path.
> How?
> > >>>> >>>
> > >>>> >>> Other options?
> > >>>> >>>
> > >>>> >>> Thank you,
> > >>>> >>> Gary
> > >>>> >>
> > >>>> >>
> > >>>>
> > >>>>
> > >>>>
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Conditional appender enablement
Posted by Matt Sicker <bo...@gmail.com>.
If I recall correctly, the NullAppender is there mainly to avoid
ClassLoader errors during shutdown in certain scenarios (e.g., shutdown
before any appenders were initialized, so the class might not be loaded
yet).
On Sun, 16 Sep 2018 at 12:03, Gary Gregory <ga...@gmail.com> wrote:
> On Sat, Sep 15, 2018 at 5:22 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
> >
> >
> > On Sat, Sep 15, 2018 at 5:16 PM Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>
> >>> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <
> ralph.goers@dslextreme.com>
> >>> wrote:
> >>>
> >>>> If you don’t want to log anything then enable a noop appender that
> just
> >>>> returns without doing anything
> >>>>
> >>>
> >>> Oh, I see we already have a NullAppender...
> >>>
> >>
> >> So I can do:
> >>
> >> <ScriptAppenderSelector name="SelectIt">
> >> <Script language="JavaScript"><![CDATA[
> >> ##SPECIAL_THING##]]>
> >> </Script>
> >> <AppenderSet>
> >> <RollingFileAppender name="MyAppender" ... />
> >> <Null/>
> >> </AppenderSet>
> >> </ScriptAppenderSelector>
> >>
> >> Not quite as simple as:
> >>
> >> <RollingFileAppender name="MyAppender" enable="##SPECIAL_THING##" ... />
> >>
> >> I often times have to walk our users through some configs so option 2 is
> >> simpler for them and less error prone... but option 1 will work for
> now...
> >>
> >
> > The not great thing here is that for each appender I want to be able to
> > toggle, I have to repeat this pattern...
> >
>
> I have something working, if ponderously, using the ScriptAppenderSelector.
> After looking at all the configs I had to update, it seems that supporting
> an "enabled" attribute would be much cleaners.
>
> Gary
>
>
> > Gary
> >
> >>
> >> Gary
> >>
> >>
> >>>
> >>> Gary
> >>>
> >>>
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com>
> >>>> wrote:
> >>>> >
> >>>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <
> >>>> ralph.goers@dslextreme.com>
> >>>> > wrote:
> >>>> >
> >>>> >> We have an appended selector for this. Why not us it?
> >>>> >>
> >>>> >
> >>>> > Hi,
> >>>> >
> >>>> > Because:
> >>>> > - Conceptually, I am not selecting an appender out of a set, I want
> >>>> the one
> >>>> > appender enabled or disabled.
> >>>> > - In practice, using a ScriptAppenderSelector with a single Appender
> >>>> means
> >>>> > my script would have to 'select' a non-existing appender when the
> >>>> script
> >>>> > evaluates to false, which would work BUT would emit an ERROR log
> >>>> event to
> >>>> > the status logger like "No node named DISABLE_ME in
> >>>> > NameOfScriptAppenderSelector". This would be a normal configuration,
> >>>> so an
> >>>> > ERROR would be very bad for our users. Changing the level of event
> >>>> would
> >>>> > not help, unless it was buried at the DEBUG level, which is not good
> >>>> for
> >>>> > the current use cases.
> >>>> > - Alternatively, we could have add a NoOpAppender which I would then
> >>>> select
> >>>> > when I want the file appender disabled. This would imply accepting
> the
> >>>> > added costs, no matter how minor in memory and speed.
> >>>> >
> >>>> > Thoughts?
> >>>> >
> >>>> > Gary
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Sent from my iPhone
> >>>> >>
> >>>> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <
> garydgregory@gmail.com>
> >>>> >> wrote:
> >>>> >>>
> >>>> >>> Hi All:
> >>>> >>>
> >>>> >>> At work, we have an installer program that installs one of five
> >>>> log4j
> >>>> >>> configs depending on what the user selects in a UI. Each of these
> 5
> >>>> >> configs
> >>>> >>> causes log events to end up in different kinds of SQL and NoSQL
> >>>> >> databases,
> >>>> >>> you pick one when you install. The installer does a brute force
> >>>> search
> >>>> >> and
> >>>> >>> replace in the log4j file to replace markers with things like
> >>>> database IP
> >>>> >>> addresses and port numbers. So far so simple and good.
> >>>> >>>
> >>>> >>> The next iteration of the installer provides an additional choice
> >>>> to log
> >>>> >> to
> >>>> >>> a file or not, in addition of one of the 5 databases.
> >>>> >>>
> >>>> >>> Option 1?
> >>>> >>> In order to avoid having 5x2 preset config files in the installer,
> >>>> I'd
> >>>> >> like
> >>>> >>> to add the file config to each of the existing 5 configurations
> and
> >>>> have
> >>>> >>> the file appender enabled or not based on a boolean flag that the
> >>>> >> installer
> >>>> >>> can implement as part of its search and replace. You'd end up
> with:
> >>>> >>>
> >>>> >>> <AppenderRef ref="foo" enabled="true|false" />
> >>>> >>> <AppenderFoo enabled="true|false" />
> >>>> >>>
> >>>> >>> If an appender is disabled it does not end up in the Log4j object
> >>>> tree at
> >>>> >>> all. It is like it never existed in the config file.
> >>>> >>>
> >>>> >>> Option 2?
> >>>> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file
> and
> >>>> have
> >>>> >>> Log4j combine it with the other log4j.xml on the class path. How?
> >>>> >>>
> >>>> >>> Other options?
> >>>> >>>
> >>>> >>> Thank you,
> >>>> >>> Gary
> >>>> >>
> >>>> >>
> >>>>
> >>>>
> >>>>
>
--
Matt Sicker <bo...@gmail.com>
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 15, 2018 at 5:22 PM Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Sat, Sep 15, 2018 at 5:16 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
>>
>>
>> On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> If you don’t want to log anything then enable a noop appender that just
>>>> returns without doing anything
>>>>
>>>
>>> Oh, I see we already have a NullAppender...
>>>
>>
>> So I can do:
>>
>> <ScriptAppenderSelector name="SelectIt">
>> <Script language="JavaScript"><![CDATA[
>> ##SPECIAL_THING##]]>
>> </Script>
>> <AppenderSet>
>> <RollingFileAppender name="MyAppender" ... />
>> <Null/>
>> </AppenderSet>
>> </ScriptAppenderSelector>
>>
>> Not quite as simple as:
>>
>> <RollingFileAppender name="MyAppender" enable="##SPECIAL_THING##" ... />
>>
>> I often times have to walk our users through some configs so option 2 is
>> simpler for them and less error prone... but option 1 will work for now...
>>
>
> The not great thing here is that for each appender I want to be able to
> toggle, I have to repeat this pattern...
>
I have something working, if ponderously, using the ScriptAppenderSelector.
After looking at all the configs I had to update, it seems that supporting
an "enabled" attribute would be much cleaners.
Gary
> Gary
>
>>
>> Gary
>>
>>
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>> >
>>>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <
>>>> ralph.goers@dslextreme.com>
>>>> > wrote:
>>>> >
>>>> >> We have an appended selector for this. Why not us it?
>>>> >>
>>>> >
>>>> > Hi,
>>>> >
>>>> > Because:
>>>> > - Conceptually, I am not selecting an appender out of a set, I want
>>>> the one
>>>> > appender enabled or disabled.
>>>> > - In practice, using a ScriptAppenderSelector with a single Appender
>>>> means
>>>> > my script would have to 'select' a non-existing appender when the
>>>> script
>>>> > evaluates to false, which would work BUT would emit an ERROR log
>>>> event to
>>>> > the status logger like "No node named DISABLE_ME in
>>>> > NameOfScriptAppenderSelector". This would be a normal configuration,
>>>> so an
>>>> > ERROR would be very bad for our users. Changing the level of event
>>>> would
>>>> > not help, unless it was buried at the DEBUG level, which is not good
>>>> for
>>>> > the current use cases.
>>>> > - Alternatively, we could have add a NoOpAppender which I would then
>>>> select
>>>> > when I want the file appender disabled. This would imply accepting the
>>>> > added costs, no matter how minor in memory and speed.
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Gary
>>>> >
>>>> >
>>>> >>
>>>> >> Sent from my iPhone
>>>> >>
>>>> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Hi All:
>>>> >>>
>>>> >>> At work, we have an installer program that installs one of five
>>>> log4j
>>>> >>> configs depending on what the user selects in a UI. Each of these 5
>>>> >> configs
>>>> >>> causes log events to end up in different kinds of SQL and NoSQL
>>>> >> databases,
>>>> >>> you pick one when you install. The installer does a brute force
>>>> search
>>>> >> and
>>>> >>> replace in the log4j file to replace markers with things like
>>>> database IP
>>>> >>> addresses and port numbers. So far so simple and good.
>>>> >>>
>>>> >>> The next iteration of the installer provides an additional choice
>>>> to log
>>>> >> to
>>>> >>> a file or not, in addition of one of the 5 databases.
>>>> >>>
>>>> >>> Option 1?
>>>> >>> In order to avoid having 5x2 preset config files in the installer,
>>>> I'd
>>>> >> like
>>>> >>> to add the file config to each of the existing 5 configurations and
>>>> have
>>>> >>> the file appender enabled or not based on a boolean flag that the
>>>> >> installer
>>>> >>> can implement as part of its search and replace. You'd end up with:
>>>> >>>
>>>> >>> <AppenderRef ref="foo" enabled="true|false" />
>>>> >>> <AppenderFoo enabled="true|false" />
>>>> >>>
>>>> >>> If an appender is disabled it does not end up in the Log4j object
>>>> tree at
>>>> >>> all. It is like it never existed in the config file.
>>>> >>>
>>>> >>> Option 2?
>>>> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and
>>>> have
>>>> >>> Log4j combine it with the other log4j.xml on the class path. How?
>>>> >>>
>>>> >>> Other options?
>>>> >>>
>>>> >>> Thank you,
>>>> >>> Gary
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 15, 2018 at 5:16 PM Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <ga...@gmail.com>
> wrote:
>
>> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> If you don’t want to log anything then enable a noop appender that just
>>> returns without doing anything
>>>
>>
>> Oh, I see we already have a NullAppender...
>>
>
> So I can do:
>
> <ScriptAppenderSelector name="SelectIt">
> <Script language="JavaScript"><![CDATA[
> ##SPECIAL_THING##]]>
> </Script>
> <AppenderSet>
> <RollingFileAppender name="MyAppender" ... />
> <Null/>
> </AppenderSet>
> </ScriptAppenderSelector>
>
> Not quite as simple as:
>
> <RollingFileAppender name="MyAppender" enable="##SPECIAL_THING##" ... />
>
> I often times have to walk our users through some configs so option 2 is
> simpler for them and less error prone... but option 1 will work for now...
>
The not great thing here is that for each appender I want to be able to
toggle, I have to repeat this pattern...
Gary
>
> Gary
>
>
>>
>> Gary
>>
>>
>>>
>>> Sent from my iPhone
>>>
>>> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>> >
>>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>> > wrote:
>>> >
>>> >> We have an appended selector for this. Why not us it?
>>> >>
>>> >
>>> > Hi,
>>> >
>>> > Because:
>>> > - Conceptually, I am not selecting an appender out of a set, I want
>>> the one
>>> > appender enabled or disabled.
>>> > - In practice, using a ScriptAppenderSelector with a single Appender
>>> means
>>> > my script would have to 'select' a non-existing appender when the
>>> script
>>> > evaluates to false, which would work BUT would emit an ERROR log event
>>> to
>>> > the status logger like "No node named DISABLE_ME in
>>> > NameOfScriptAppenderSelector". This would be a normal configuration,
>>> so an
>>> > ERROR would be very bad for our users. Changing the level of event
>>> would
>>> > not help, unless it was buried at the DEBUG level, which is not good
>>> for
>>> > the current use cases.
>>> > - Alternatively, we could have add a NoOpAppender which I would then
>>> select
>>> > when I want the file appender disabled. This would imply accepting the
>>> > added costs, no matter how minor in memory and speed.
>>> >
>>> > Thoughts?
>>> >
>>> > Gary
>>> >
>>> >
>>> >>
>>> >> Sent from my iPhone
>>> >>
>>> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi All:
>>> >>>
>>> >>> At work, we have an installer program that installs one of five log4j
>>> >>> configs depending on what the user selects in a UI. Each of these 5
>>> >> configs
>>> >>> causes log events to end up in different kinds of SQL and NoSQL
>>> >> databases,
>>> >>> you pick one when you install. The installer does a brute force
>>> search
>>> >> and
>>> >>> replace in the log4j file to replace markers with things like
>>> database IP
>>> >>> addresses and port numbers. So far so simple and good.
>>> >>>
>>> >>> The next iteration of the installer provides an additional choice to
>>> log
>>> >> to
>>> >>> a file or not, in addition of one of the 5 databases.
>>> >>>
>>> >>> Option 1?
>>> >>> In order to avoid having 5x2 preset config files in the installer,
>>> I'd
>>> >> like
>>> >>> to add the file config to each of the existing 5 configurations and
>>> have
>>> >>> the file appender enabled or not based on a boolean flag that the
>>> >> installer
>>> >>> can implement as part of its search and replace. You'd end up with:
>>> >>>
>>> >>> <AppenderRef ref="foo" enabled="true|false" />
>>> >>> <AppenderFoo enabled="true|false" />
>>> >>>
>>> >>> If an appender is disabled it does not end up in the Log4j object
>>> tree at
>>> >>> all. It is like it never existed in the config file.
>>> >>>
>>> >>> Option 2?
>>> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and
>>> have
>>> >>> Log4j combine it with the other log4j.xml on the class path. How?
>>> >>>
>>> >>> Other options?
>>> >>>
>>> >>> Thank you,
>>> >>> Gary
>>> >>
>>> >>
>>>
>>>
>>>
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <ga...@gmail.com> wrote:
> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> If you don’t want to log anything then enable a noop appender that just
>> returns without doing anything
>>
>
> Oh, I see we already have a NullAppender...
>
So I can do:
<ScriptAppenderSelector name="SelectIt">
<Script language="JavaScript"><![CDATA[
##SPECIAL_THING##]]>
</Script>
<AppenderSet>
<RollingFileAppender name="MyAppender" ... />
<Null/>
</AppenderSet>
</ScriptAppenderSelector>
Not quite as simple as:
<RollingFileAppender name="MyAppender" enable="##SPECIAL_THING##" ... />
I often times have to walk our users through some configs so option 2 is
simpler for them and less error prone... but option 1 will work for now...
Gary
>
> Gary
>
>
>>
>> Sent from my iPhone
>>
>> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <ralph.goers@dslextreme.com
>> >
>> > wrote:
>> >
>> >> We have an appended selector for this. Why not us it?
>> >>
>> >
>> > Hi,
>> >
>> > Because:
>> > - Conceptually, I am not selecting an appender out of a set, I want the
>> one
>> > appender enabled or disabled.
>> > - In practice, using a ScriptAppenderSelector with a single Appender
>> means
>> > my script would have to 'select' a non-existing appender when the script
>> > evaluates to false, which would work BUT would emit an ERROR log event
>> to
>> > the status logger like "No node named DISABLE_ME in
>> > NameOfScriptAppenderSelector". This would be a normal configuration, so
>> an
>> > ERROR would be very bad for our users. Changing the level of event would
>> > not help, unless it was buried at the DEBUG level, which is not good for
>> > the current use cases.
>> > - Alternatively, we could have add a NoOpAppender which I would then
>> select
>> > when I want the file appender disabled. This would imply accepting the
>> > added costs, no matter how minor in memory and speed.
>> >
>> > Thoughts?
>> >
>> > Gary
>> >
>> >
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi All:
>> >>>
>> >>> At work, we have an installer program that installs one of five log4j
>> >>> configs depending on what the user selects in a UI. Each of these 5
>> >> configs
>> >>> causes log events to end up in different kinds of SQL and NoSQL
>> >> databases,
>> >>> you pick one when you install. The installer does a brute force search
>> >> and
>> >>> replace in the log4j file to replace markers with things like
>> database IP
>> >>> addresses and port numbers. So far so simple and good.
>> >>>
>> >>> The next iteration of the installer provides an additional choice to
>> log
>> >> to
>> >>> a file or not, in addition of one of the 5 databases.
>> >>>
>> >>> Option 1?
>> >>> In order to avoid having 5x2 preset config files in the installer, I'd
>> >> like
>> >>> to add the file config to each of the existing 5 configurations and
>> have
>> >>> the file appender enabled or not based on a boolean flag that the
>> >> installer
>> >>> can implement as part of its search and replace. You'd end up with:
>> >>>
>> >>> <AppenderRef ref="foo" enabled="true|false" />
>> >>> <AppenderFoo enabled="true|false" />
>> >>>
>> >>> If an appender is disabled it does not end up in the Log4j object
>> tree at
>> >>> all. It is like it never existed in the config file.
>> >>>
>> >>> Option 2?
>> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and
>> have
>> >>> Log4j combine it with the other log4j.xml on the class path. How?
>> >>>
>> >>> Other options?
>> >>>
>> >>> Thank you,
>> >>> Gary
>> >>
>> >>
>>
>>
>>
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> If you don’t want to log anything then enable a noop appender that just
> returns without doing anything
>
Oh, I see we already have a NullAppender...
Gary
>
> Sent from my iPhone
>
> > On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> We have an appended selector for this. Why not us it?
> >>
> >
> > Hi,
> >
> > Because:
> > - Conceptually, I am not selecting an appender out of a set, I want the
> one
> > appender enabled or disabled.
> > - In practice, using a ScriptAppenderSelector with a single Appender
> means
> > my script would have to 'select' a non-existing appender when the script
> > evaluates to false, which would work BUT would emit an ERROR log event to
> > the status logger like "No node named DISABLE_ME in
> > NameOfScriptAppenderSelector". This would be a normal configuration, so
> an
> > ERROR would be very bad for our users. Changing the level of event would
> > not help, unless it was buried at the DEBUG level, which is not good for
> > the current use cases.
> > - Alternatively, we could have add a NoOpAppender which I would then
> select
> > when I want the file appender disabled. This would imply accepting the
> > added costs, no matter how minor in memory and speed.
> >
> > Thoughts?
> >
> > Gary
> >
> >
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
> >> wrote:
> >>>
> >>> Hi All:
> >>>
> >>> At work, we have an installer program that installs one of five log4j
> >>> configs depending on what the user selects in a UI. Each of these 5
> >> configs
> >>> causes log events to end up in different kinds of SQL and NoSQL
> >> databases,
> >>> you pick one when you install. The installer does a brute force search
> >> and
> >>> replace in the log4j file to replace markers with things like database
> IP
> >>> addresses and port numbers. So far so simple and good.
> >>>
> >>> The next iteration of the installer provides an additional choice to
> log
> >> to
> >>> a file or not, in addition of one of the 5 databases.
> >>>
> >>> Option 1?
> >>> In order to avoid having 5x2 preset config files in the installer, I'd
> >> like
> >>> to add the file config to each of the existing 5 configurations and
> have
> >>> the file appender enabled or not based on a boolean flag that the
> >> installer
> >>> can implement as part of its search and replace. You'd end up with:
> >>>
> >>> <AppenderRef ref="foo" enabled="true|false" />
> >>> <AppenderFoo enabled="true|false" />
> >>>
> >>> If an appender is disabled it does not end up in the Log4j object tree
> at
> >>> all. It is like it never existed in the config file.
> >>>
> >>> Option 2?
> >>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and
> have
> >>> Log4j combine it with the other log4j.xml on the class path. How?
> >>>
> >>> Other options?
> >>>
> >>> Thank you,
> >>> Gary
> >>
> >>
>
>
>
Re: Conditional appender enablement
Posted by Ralph Goers <ra...@dslextreme.com>.
If you don’t want to log anything then enable a noop appender that just returns without doing anything
Sent from my iPhone
> On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> We have an appended selector for this. Why not us it?
>>
>
> Hi,
>
> Because:
> - Conceptually, I am not selecting an appender out of a set, I want the one
> appender enabled or disabled.
> - In practice, using a ScriptAppenderSelector with a single Appender means
> my script would have to 'select' a non-existing appender when the script
> evaluates to false, which would work BUT would emit an ERROR log event to
> the status logger like "No node named DISABLE_ME in
> NameOfScriptAppenderSelector". This would be a normal configuration, so an
> ERROR would be very bad for our users. Changing the level of event would
> not help, unless it was buried at the DEBUG level, which is not good for
> the current use cases.
> - Alternatively, we could have add a NoOpAppender which I would then select
> when I want the file appender disabled. This would imply accepting the
> added costs, no matter how minor in memory and speed.
>
> Thoughts?
>
> Gary
>
>
>>
>> Sent from my iPhone
>>
>>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>> Hi All:
>>>
>>> At work, we have an installer program that installs one of five log4j
>>> configs depending on what the user selects in a UI. Each of these 5
>> configs
>>> causes log events to end up in different kinds of SQL and NoSQL
>> databases,
>>> you pick one when you install. The installer does a brute force search
>> and
>>> replace in the log4j file to replace markers with things like database IP
>>> addresses and port numbers. So far so simple and good.
>>>
>>> The next iteration of the installer provides an additional choice to log
>> to
>>> a file or not, in addition of one of the 5 databases.
>>>
>>> Option 1?
>>> In order to avoid having 5x2 preset config files in the installer, I'd
>> like
>>> to add the file config to each of the existing 5 configurations and have
>>> the file appender enabled or not based on a boolean flag that the
>> installer
>>> can implement as part of its search and replace. You'd end up with:
>>>
>>> <AppenderRef ref="foo" enabled="true|false" />
>>> <AppenderFoo enabled="true|false" />
>>>
>>> If an appender is disabled it does not end up in the Log4j object tree at
>>> all. It is like it never existed in the config file.
>>>
>>> Option 2?
>>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and have
>>> Log4j combine it with the other log4j.xml on the class path. How?
>>>
>>> Other options?
>>>
>>> Thank you,
>>> Gary
>>
>>
Re: Conditional appender enablement
Posted by Ralph Goers <ra...@dslextreme.com>.
Or make sure it’s logging level causes it to never log
Sent from my iPhone
> On Sep 15, 2018, at 12:34 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> We have an appended selector for this. Why not us it?
>>
>
> Hi,
>
> Because:
> - Conceptually, I am not selecting an appender out of a set, I want the one
> appender enabled or disabled.
> - In practice, using a ScriptAppenderSelector with a single Appender means
> my script would have to 'select' a non-existing appender when the script
> evaluates to false, which would work BUT would emit an ERROR log event to
> the status logger like "No node named DISABLE_ME in
> NameOfScriptAppenderSelector". This would be a normal configuration, so an
> ERROR would be very bad for our users. Changing the level of event would
> not help, unless it was buried at the DEBUG level, which is not good for
> the current use cases.
> - Alternatively, we could have add a NoOpAppender which I would then select
> when I want the file appender disabled. This would imply accepting the
> added costs, no matter how minor in memory and speed.
>
> Thoughts?
>
> Gary
>
>
>>
>> Sent from my iPhone
>>
>>> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>
>>> Hi All:
>>>
>>> At work, we have an installer program that installs one of five log4j
>>> configs depending on what the user selects in a UI. Each of these 5
>> configs
>>> causes log events to end up in different kinds of SQL and NoSQL
>> databases,
>>> you pick one when you install. The installer does a brute force search
>> and
>>> replace in the log4j file to replace markers with things like database IP
>>> addresses and port numbers. So far so simple and good.
>>>
>>> The next iteration of the installer provides an additional choice to log
>> to
>>> a file or not, in addition of one of the 5 databases.
>>>
>>> Option 1?
>>> In order to avoid having 5x2 preset config files in the installer, I'd
>> like
>>> to add the file config to each of the existing 5 configurations and have
>>> the file appender enabled or not based on a boolean flag that the
>> installer
>>> can implement as part of its search and replace. You'd end up with:
>>>
>>> <AppenderRef ref="foo" enabled="true|false" />
>>> <AppenderFoo enabled="true|false" />
>>>
>>> If an appender is disabled it does not end up in the Log4j object tree at
>>> all. It is like it never existed in the config file.
>>>
>>> Option 2?
>>> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and have
>>> Log4j combine it with the other log4j.xml on the class path. How?
>>>
>>> Other options?
>>>
>>> Thank you,
>>> Gary
>>
>>
Re: Conditional appender enablement
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers <ra...@dslextreme.com>
wrote:
> We have an appended selector for this. Why not us it?
>
Hi,
Because:
- Conceptually, I am not selecting an appender out of a set, I want the one
appender enabled or disabled.
- In practice, using a ScriptAppenderSelector with a single Appender means
my script would have to 'select' a non-existing appender when the script
evaluates to false, which would work BUT would emit an ERROR log event to
the status logger like "No node named DISABLE_ME in
NameOfScriptAppenderSelector". This would be a normal configuration, so an
ERROR would be very bad for our users. Changing the level of event would
not help, unless it was buried at the DEBUG level, which is not good for
the current use cases.
- Alternatively, we could have add a NoOpAppender which I would then select
when I want the file appender disabled. This would imply accepting the
added costs, no matter how minor in memory and speed.
Thoughts?
Gary
>
> Sent from my iPhone
>
> > On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Hi All:
> >
> > At work, we have an installer program that installs one of five log4j
> > configs depending on what the user selects in a UI. Each of these 5
> configs
> > causes log events to end up in different kinds of SQL and NoSQL
> databases,
> > you pick one when you install. The installer does a brute force search
> and
> > replace in the log4j file to replace markers with things like database IP
> > addresses and port numbers. So far so simple and good.
> >
> > The next iteration of the installer provides an additional choice to log
> to
> > a file or not, in addition of one of the 5 databases.
> >
> > Option 1?
> > In order to avoid having 5x2 preset config files in the installer, I'd
> like
> > to add the file config to each of the existing 5 configurations and have
> > the file appender enabled or not based on a boolean flag that the
> installer
> > can implement as part of its search and replace. You'd end up with:
> >
> > <AppenderRef ref="foo" enabled="true|false" />
> > <AppenderFoo enabled="true|false" />
> >
> > If an appender is disabled it does not end up in the Log4j object tree at
> > all. It is like it never existed in the config file.
> >
> > Option 2?
> > Add a second log4j2.xml, say log4j2-rollingfile.xml config file and have
> > Log4j combine it with the other log4j.xml on the class path. How?
> >
> > Other options?
> >
> > Thank you,
> > Gary
>
>
Re: Conditional appender enablement
Posted by Ralph Goers <ra...@dslextreme.com>.
We have an appended selector for this. Why not us it?
Sent from my iPhone
> On Sep 15, 2018, at 11:07 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All:
>
> At work, we have an installer program that installs one of five log4j
> configs depending on what the user selects in a UI. Each of these 5 configs
> causes log events to end up in different kinds of SQL and NoSQL databases,
> you pick one when you install. The installer does a brute force search and
> replace in the log4j file to replace markers with things like database IP
> addresses and port numbers. So far so simple and good.
>
> The next iteration of the installer provides an additional choice to log to
> a file or not, in addition of one of the 5 databases.
>
> Option 1?
> In order to avoid having 5x2 preset config files in the installer, I'd like
> to add the file config to each of the existing 5 configurations and have
> the file appender enabled or not based on a boolean flag that the installer
> can implement as part of its search and replace. You'd end up with:
>
> <AppenderRef ref="foo" enabled="true|false" />
> <AppenderFoo enabled="true|false" />
>
> If an appender is disabled it does not end up in the Log4j object tree at
> all. It is like it never existed in the config file.
>
> Option 2?
> Add a second log4j2.xml, say log4j2-rollingfile.xml config file and have
> Log4j combine it with the other log4j.xml on the class path. How?
>
> Other options?
>
> Thank you,
> Gary