Hi All: I have attached a patch to a new issue: LOG4J2-413 "PatternLayout option to not output ANSI escape codes if no Console is available"
https://issues.apache.org/jira/browse/LOG4J2-413 Can anyone think of a better way to do this? It would be easy to offer this without any option. But as I describe in the issue, I think it should be an option. I found it hard to connect the configuration to the code that needs to know it. Too hard in fact. It feels like something is missing in the configuration. I suppose this is not a point of view the code has needed before. Please advise. Thank you, Gary On Tue, Sep 24, 2013 at 9:49 AM, Gary Gregory <[email protected]>wrote: > On Thu, Sep 12, 2013 at 12:26 AM, Gary Gregory <[email protected]>wrote: > >> Hi All, >> >> I have a solution implemented locally that does not output ANSI escapes >> if there is no console (it logs a warning to the status logger if it >> detects this condition on start up). >> >> I am wondering if the Console element should have an attribute called >> "autoHideAnsi" or some such to still output ANSI escapes even if there is >> no console. >> > > Coming back to this, I think the simplest solution is to add an attribute > to PatternLayout. Does anyone have a better name than autoHideAnsi? > > Gary > > >> Gary >> >> >> On Wed, Sep 11, 2013 at 11:12 PM, Gary Gregory <[email protected]>wrote: >> >>> Hi All: >>> >>> Here is my pickle: >>> >>> I have a stock XML config file I package with a standalone app. >>> >>> When I run it on the Windows command line, I want to use a JAnsi logger, >>> it works. >>> >>> When I run the app within Eclipse, the Eclipse console displays junk for >>> the escape codes, not so nice. >>> >>> So I'd like Log4J to use a plain Console appender in this case. >>> >>> The question is: >>> >>> Should Log4J detect that there is no real console? If you call >>> "java.io.Console.console()" from Eclipse, you get null, so that would be >>> one way to gracefully detect that there is no console. >>> >>> Or: >>> >>> Should I be able to have some condition in the config that says if ... >>> enable this appender else enable that one. >>> >>> Or: >>> >>> Should I be able to configure each appender with an "unless" attibute >>> (like in Ant) that tells Log4j to enable the appender unless some condition >>> is not met. It could be "if" instead of "unless" but you get the idea. >>> >>> Thoughts? >>> >>> -- >>> E-Mail: [email protected] | [email protected] >>> 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: [email protected] | [email protected] >> 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: [email protected] | [email protected] > 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: [email protected] | [email protected] 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
