[ 
https://issues.apache.org/jira/browse/LOG4J2-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15658069#comment-15658069
 ] 

Gary Gregory commented on LOG4J2-1685:
--------------------------------------

Hi All,

I added the {{noConsoleNoAnsi}} option to workaround a Java feature that in 
some environments, the console is null but you can still use 
{{System.out.println(...)}}. So you do not really have a console. In Eclipse 
for example, you can enable ANSI logging but you'll get gobbledygook characters 
on the Eclipse Console View. So {{noConsoleNoAnsi}}  let's you work around that 
and output non-ANSI text. But, you can also install an ANSI console plugin in 
Eclipse, as a way to actually SEE the colors properly. So... it's a bit 
complicated of a situation and there you have it ;-)

For this ticket it sounds like we want to have ANSI in patterns but just get 
rid of 'em based on a toggle, somewhere.

I think you can already achieve this with our new feature in 2.7 using 
configuration Scripts. See 
https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts

Looking at the patch, I see that the implementation of {{disableAnsi}} 
parallels {{noConsoleNoAnsi}}.

I do not see an example use case though in the form of a configuration file. So 
here is an example:

{code:xml}
      <PatternLayout noConsoleNoAnsi="true" disableAnsi="true"
        pattern="%style{%d}{white} %style{[%t]}{blue} %style{%-5level:}{yellow} 
%style{%msg%n%throwable{short}}{green}" />
{code}

I guess that would work and you could base the value of {{disableAnsi}} on a 
system property.

For good or bad, the patch contains a LOT of changes and some BC breaks for 
some plugins like {{ScriptPatternSelector}}, but that's just they way it has to 
be. I recall having made a lot of changes for {{noConsoleNoAnsi}} as well. I 
wish there was a way to refactor all of this to be less intrusive.

I know that we do not make any hard guarantees WRT 100% BC in the 
{{log4j-core}} module, but we also try to avoid putting our users in jar hell 
as much as possible. That said, I wonder if we should switch some of the 
plugins to the builder pattern BEFORE applying this patch so that the changes 
would be a perhaps cleaner. This would avoid SOME BC breaks.

The builder pattern would be applied to:

- {{ScriptPatternSelector}}
- {{MarkerPatternSelector}}
- {{PatternLayout.Builder}} does not have a {{disableAnsi}} but it DOES have a 
{{noConsoleNoAnsi}}. Is that a bug/omission?

There would still some BC breaks, but fewer. We could probably use the builder 
pattern to some non-plugin classes and further minimize BC breaks. For example, 
to avoid BC breaks in {{PatternLayout.createSerializer(Configuration, 
RegexReplacement, String, String, PatternSelector, boolean, boolean)}}.

Yeah, now that I think about it, I really like the idea of using builders to 
minimize BC breaks.

Thoughts?

Gary


> Single property to disable all color output
> -------------------------------------------
>
>                 Key: LOG4J2-1685
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1685
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Appenders
>    Affects Versions: 2.7
>            Reporter: Raman Gupta
>            Assignee: Mikael Ståldal
>            Priority: Minor
>
> I am deploying an app to a Windows server. The app will write logs to 
> standard output which will then be captured by some wrapper process.
> My default configuration contains ansi escapes for color, because they are 
> nice for every situation except this one.
> It would be nice if there was a simple way to disable all ansi output via a 
> system property and/or environment variable e.g.
> `-Dlog4j.ansi.enabled=false`
> This would operate similarly to the Spring Boot `spring.output.ansi.enabled` 
> property 
> (http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html).
> In Spring Boot I believe this is handled by using conditionals in their 
> logback configuration (which would be super-nice in log4j also). With 
> conditional layout I could very easily do this myself by specifying two 
> different Pattern layouts in my config file, one with color and one without, 
> conditional on some system property or env var I define.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to