[jira] [Commented] (TINKERPOP-1983) Update Log4j to Log4j2
[
https://issues.apache.org/jira/browse/TINKERPOP-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563721#comment-16563721
]
Florian Hockmann commented on TINKERPOP-1983:
-
First, thanks for the link. Configuring Logback is probably a good solution for
most users.
I still think that we should try to not depend on a library that isn't
maintained anymore. But if it's not feasible to update this dependency right
now because Spark and Hadoop still use it in that version, then I'm ok to close
the ticket for now and we can reconsider later when those two projects updated
to a newer version of log4j.
> Update Log4j to Log4j2
> --
>
> Key: TINKERPOP-1983
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1983
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.3.3
>Reporter: Florian Hockmann
>Priority: Minor
>
> TinkerPop uses Log4j version 1.2.17 but Log4j 1 reached end of life almost
> three years ago:
> {quote}On August 5, 2015 the Logging Services Project Management Committee
> announced that Log4j 1.x had reached end of life.
> {quote}
> Source: [http://logging.apache.org/log4j/1.2/]
> It would be great if we could update to Log4j2 as it brings some nice
> benefits like new logging layouts for example (one of them is the JSON layout
> which is very useful to have to collect logs in something like the ELK stack
> or Graylog).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1983) Update Log4j to Log4j2
[
https://issues.apache.org/jira/browse/TINKERPOP-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563662#comment-16563662
]
stephen mallette commented on TINKERPOP-1983:
-
I did a quick look around on this and it's a bit of a mess to upgrade, plus
spark/hadoop are still on the version we're on. I think the solution though to
your specific problem is to just switch the logger out. We don't require you to
use log4j, we just use it internally and package it for convenience in server
and console zip distributions. All of our logging runs through slf4j, so you
can just change out log4j for logback (which will support JSON as you'd like) -
that's the exact use case for using slf4j in the first place. There's some
discussion here on how to do this setup here:
https://gquintana.github.io/2017/12/01/Structured-logging-with-SL-FJ-and-Logback.html
will that work ok enough for me to close this?
> Update Log4j to Log4j2
> --
>
> Key: TINKERPOP-1983
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1983
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.3.3
>Reporter: Florian Hockmann
>Priority: Minor
>
> TinkerPop uses Log4j version 1.2.17 but Log4j 1 reached end of life almost
> three years ago:
> {quote}On August 5, 2015 the Logging Services Project Management Committee
> announced that Log4j 1.x had reached end of life.
> {quote}
> Source: [http://logging.apache.org/log4j/1.2/]
> It would be great if we could update to Log4j2 as it brings some nice
> benefits like new logging layouts for example (one of them is the JSON layout
> which is very useful to have to collect logs in something like the ELK stack
> or Graylog).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1983) Update Log4j to Log4j2
[
https://issues.apache.org/jira/browse/TINKERPOP-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508271#comment-16508271
]
stephen mallette commented on TINKERPOP-1983:
-
ok - i was just wondering. thanks for the explanation.
> My understanding of logging in Java was that Logback defines the interface
> and Log4j is the implementation that could be replaced by any other
> implementation of Logback.
Technically, its slf4j defining the interface and then you can replace the
implementation with what you want. I sense that it shouldn't be impossible, but
it's not going to be as easy as just bumping the version number. I think this
change would have to occur in a breaking release because we bundle log4j with
the console/server (i think) and thus someone might depend on that. For
standard maven dependencies I believe the slf4j implementation is up to the
user as it should be so nothing should be a problem there. I also think that
certain tests rely on log4j, so if the API changes by 2.x then those would have
to be dealt with. Finally, i guess if there were changes to any of the log4j
config files then those would need update too.
> Update Log4j to Log4j2
> --
>
> Key: TINKERPOP-1983
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1983
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.3.3
>Reporter: Florian Hockmann
>Priority: Minor
>
> TinkerPop uses Log4j version 1.2.17 but Log4j 1 reached end of life almost
> three years ago:
> {quote}On August 5, 2015 the Logging Services Project Management Committee
> announced that Log4j 1.x had reached end of life.
> {quote}
> Source: [http://logging.apache.org/log4j/1.2/]
> It would be great if we could update to Log4j2 as it brings some nice
> benefits like new logging layouts for example (one of them is the JSON layout
> which is very useful to have to collect logs in something like the ELK stack
> or Graylog).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1983) Update Log4j to Log4j2
[
https://issues.apache.org/jira/browse/TINKERPOP-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508262#comment-16508262
]
Florian Hockmann commented on TINKERPOP-1983:
-
My motivation here was in this case simply that I wanted to use the JSON layout
that is now included by default in Log4j2 but needs a third party library in
Log4j 1. That isn't a big problem of course but it requires to manually copy
the required jars and I think that needing a JSON layout is a frequent use case
nowadays as most users probably use something like Graylog or the ELK stack to
collect logs and make them searchable.
Also I would of course prefer if we wouldn't have to use a library that isn't
maintained since 2015, but I have no idea how much effort such an upgrade would
require as I'm not a Java developer. My understanding of logging in Java was
that Logback defines the interface and Log4j is the implementation that could
be replaced by any other implementation of Logback. So my hope was that it
wouldn't require any code changes.
> Update Log4j to Log4j2
> --
>
> Key: TINKERPOP-1983
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1983
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release
>Affects Versions: 3.3.3
>Reporter: Florian Hockmann
>Priority: Minor
>
> TinkerPop uses Log4j version 1.2.17 but Log4j 1 reached end of life almost
> three years ago:
> {quote}On August 5, 2015 the Logging Services Project Management Committee
> announced that Log4j 1.x had reached end of life.
> {quote}
> Source: [http://logging.apache.org/log4j/1.2/]
> It would be great if we could update to Log4j2 as it brings some nice
> benefits like new logging layouts for example (one of them is the JSON layout
> which is very useful to have to collect logs in something like the ELK stack
> or Graylog).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
