On Sat, Sep 15, 2018 at 5:16 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> > > On Sat, Sep 15, 2018 at 4:43 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > >> On Sat, Sep 15, 2018 at 4:40 PM Ralph Goers <ralph.go...@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 <garydgreg...@gmail.com> >>> wrote: >>> > >>> > On Sat, Sep 15, 2018 at 3:24 PM Ralph Goers < >>> ralph.go...@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 <garydgreg...@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 >>> >> >>> >> >>> >>> >>>
