Yes. https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/java/org/apache/logging/log4j/core/appender/rewrite/RewriteAppenderTest.java uses https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/resources/log4j-rewrite.xml which uses a MapRewritePolicy. You would replace that with your own RewritePolicy. https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/java/org/apache/logging/log4j/core/appender/rewrite/TestRewritePolicy.java shows a sample RewritePolicy. Basically you just create a new LogEvent copying data from the input LogEvent modifying that data as needed.
Ralph On Jan 21, 2014, at 3:38 PM, Saibabu Vallurupalli <[email protected]> wrote: > Hi Scott and Team: > > I tried to research on the internet on how to use this functionality but very > limited information. Do we have a Unit test case showing this scenario in the > source code? Or any reference implementation will be really helpful to refer > and try in my Application. > > Please advise. > > Thank you, > Sai > > > On Tue, Jan 21, 2014 at 5:57 PM, Scott Deboy <[email protected]> wrote: > This mechanism is also available in log4j 1.2: > > https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/rewrite/RewriteAppender.html > > > On 1/21/14, Scott Deboy <[email protected]> wrote: > > See > > http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender > > > > On 1/21/14, Saibabu Vallurupalli <[email protected]> wrote: > >> First of all Thanks so much for you all for the quickest response for > >> this > >> posting. I am thinking of writing a wrapper class and update the source, > >> but we have about 2400 Java classes in the application which needs to be > >> updated and are using log4j logger. I am trying to explore the option to > >> avoid modifying all these classes with some kind of ingestion. Any > >> suggestions around will be greatly appreciated. > >> > >> Thank you, > >> Sai > >> > >> > >> > >> On Tue, Jan 21, 2014 at 5:20 PM, Paul Benedict <[email protected]> > >> wrote: > >> > >>> This is not an unusual requirement. I've been at a company that tries to > >>> scrub log files from certain patterns (like SSN #s). Can that be done in > >>> log4j? I don't know. It would be interesting to know if 2.0 had some > >>> sort > >>> of filtering capability. Remko? Gary? Ralph? > >>> > >>> > >>> On Tue, Jan 21, 2014 at 4:16 PM, Saibabu Vallurupalli < > >>> [email protected]> wrote: > >>> > >>>> So, we wanted to inspect the message which is getting logged out to > >>>> avoid > >>>> possible security issues. So, what exactly I am looking is If I wanted > >>>> to > >>>> add a restriction on whats been logged. How can I achieve this? > >>>> > >>>> For example: log.info("user name"+username+"Password"+password); // > >>>> This > >>>> is just an example if I see a message having password do not log it or > >>>> take > >>>> some action. > >>>> > >>>> Please advise. > >>>> > >>>> Thank you, > >>>> Sai > >>>> > >>>> > >>>> On Tue, Jan 21, 2014 at 5:12 PM, Remko Popma > >>>> <[email protected]>wrote: > >>>> > >>>>> Sorry, but I have no idea what you mean by "neutralize out". > >>>>> What is currently happening and what would you like to happen instead? > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> > On 2014/01/22, at 6:29, Saibabu Vallurupalli < > >>>>> [email protected]> wrote: > >>>>> > > >>>>> > Hi, > >>>>> > > >>>>> > I am working on an issue related to logging. I our application we > >>>>> > are > >>>>> using log4j for logging and we detected our software doesn't > >>>>> neutralize > >>>>> out > >>>>> properly. Now, Is there any way without modifying the entire source by > >>>>> going through each and every class we can achieve this functionality > >>>>> of > >>>>> inspecting the message getting logged and take appropriate action. > >>>>> > > >>>>> > We appreciate your support. > >>>>> > > >>>>> > Thank you, > >>>>> > Sai > >>>>> > > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> Cheers, > >>> Paul > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
