[
https://issues.apache.org/jira/browse/LOG4J2-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15658069#comment-15658069
]
Gary Gregory edited comment on LOG4J2-1685 at 11/11/16 8:28 PM:
----------------------------------------------------------------
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 perhaps cleaner. This would avoid SOME BC breaks. The patch would then
need another iteration to adapt to the new builders.
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
was (Author: garydgregory):
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
