On Sun, Sep 16, 2018 at 11:19 AM Matt Sicker <boa...@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 <garydgreg...@gmail.com> wrote: > > > On Sat, Sep 15, 2018 at 5:22 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > > > > > > 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... > > > > > > > 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 < > 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 > > >>>> >> > > >>>> >> > > >>>> > > >>>> > > >>>> > > > > > -- > Matt Sicker <boa...@gmail.com> >
