[GitHub] [logging-log4cxx] rm5248 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
rm5248 commented on code in PR #132: URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974816672 ## src/main/include/log4cxx/hierarchy.h: ## @@ -66,15 +66,10 @@ class LOG4CXX_EXPORT Hierarchy : LOG4CXX_CAST_ENTRY(spi::LoggerRepository) END_LOG4CXX_CAST_MAP() - private: - /** - Create a new logger hierarchy. - */ - Hierarchy(); - public: static HierarchyPtr create(); + Hierarchy(); Review Comment: That seems reasonable, as long as it is a singleton(I'm fairly certain that it is). Would changing it from a `shared_ptr` to a raw pointer improve performance at all? I know it did for some other changes you had done before. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] rm5248 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
rm5248 commented on code in PR #132:
URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974812641
##
src/main/include/log4cxx/helpers/threadutility.h:
##
@@ -69,15 +69,14 @@ LOG4CXX_PTR_DEF(ThreadUtility);
class LOG4CXX_EXPORT ThreadUtility
{
private:
- ThreadUtility();
-
log4cxx::helpers::ThreadStartPre preStartFunction();
log4cxx::helpers::ThreadStarted threadStartedFunction();
log4cxx::helpers::ThreadStartPost postStartFunction();
LOG4CXX_DECLARE_PRIVATE_MEMBER_PTR(priv_data, m_priv)
public:
+ ThreadUtility();
Review Comment:
Keeping that as a `shared_ptr` makes it similar to other methods(for
consistency), but since it is a singleton making it a `ThreadUtility*` would be
fine in my opinion as well, since it is guaranteed to never be null in normal
operation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4cxx] swebb2066 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
swebb2066 commented on code in PR #132: URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974769603 ## src/main/include/log4cxx/hierarchy.h: ## @@ -66,15 +66,10 @@ class LOG4CXX_EXPORT Hierarchy : LOG4CXX_CAST_ENTRY(spi::LoggerRepository) END_LOG4CXX_CAST_MAP() - private: - /** - Create a new logger hierarchy. - */ - Hierarchy(); - public: static HierarchyPtr create(); + Hierarchy(); Review Comment: Then I should also change `LoggerRepositoryPtr Logger::getLoggerRepository () const` back to `LoggerRepository* Logger::getLoggerRepository () const` as it is in 0.13 - OK? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] swebb2066 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
swebb2066 commented on code in PR #132:
URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974766904
##
src/main/include/log4cxx/helpers/threadutility.h:
##
@@ -69,15 +69,14 @@ LOG4CXX_PTR_DEF(ThreadUtility);
class LOG4CXX_EXPORT ThreadUtility
{
private:
- ThreadUtility();
-
log4cxx::helpers::ThreadStartPre preStartFunction();
log4cxx::helpers::ThreadStarted threadStartedFunction();
log4cxx::helpers::ThreadStartPost postStartFunction();
LOG4CXX_DECLARE_PRIVATE_MEMBER_PTR(priv_data, m_priv)
public:
+ ThreadUtility();
Review Comment:
Should I change
`std::shared_ptr ThreadUtility::instance()`
to
`ThreadUtility& ThreadUtility::instance()`
or
`ThreadUtility* ThreadUtility::instance()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606784#comment-17606784
]
Ralph Goers commented on LOG4J2-3601:
-
[~pkarwasz] I originally thought the log4j-core should be optional but then I
looked at Log4jLoggerFactory and noticed that it has a hard dependency on
Log4j-core. So IMO this does need to be a runtime dependency.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606783#comment-17606783
]
Piotr Karwasz edited comment on LOG4J2-3601 at 9/19/22 10:09 PM:
-
[~ctubbsii],
The reason I didn't put {{log4j-core}} as runtime dependency for
{{log4j-slf4j2-impl}} is for consistency with {{log4j-to-slf4j}} that does not
list {{logback-classic}} as runtime dependency.
However I agree that most users will use {{log4j-slf4j2-impl}} to bind SLF4J to
Log4j2 Core and, although I might not like it, this change should be
implemented.
IMHO if you plan to ship Apache Accumulo with Log4j2 Core as its logging
backend, you should declare a runtime dependency on `log4j-core`. You might
also consider coding against the Log4j2 API directly as it has many advantages
over SLF4J (cf. [Remko's answer on
SO|https://stackoverflow.com/a/41500347/11748454]), e.g. no temporary arrays if
your message has more than 2 arguments.
was (Author: pkarwasz):
[~ctubbsii],
The reason I didn't put {{log4j-core}} as runtime dependency for
{{log4j-slf4j2-impl}} is for consistency with {{log4j-to-slf4j}} that does not
list {{logback-classic}} as runtime dependency.
However I agree that most users will use {{log4j-slf4j2-impl}} to bind SLF4J to
Log4j2 Core and, although I might not like it, this change should be
implemented.
IMHO software that ships with Log4j2 Core as its logging backend, should
declare a runtime dependency on `log4j-core`.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606783#comment-17606783
]
Piotr Karwasz commented on LOG4J2-3601:
---
[~ctubbsii],
The reason I didn't put {{log4j-core}} as runtime dependency for
{{log4j-slf4j2-impl}} is for consistency with {{log4j-to-slf4j}} that does not
list {{logback-classic}} as runtime dependency.
However I agree that most users will use {{log4j-slf4j2-impl}} to bind SLF4J to
Log4j2 Core and, although I might not like it, this change should be
implemented.
IMHO software that ships with Log4j2 Core as its logging backend, should
declare a runtime dependency on `log4j-core`.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3602) Don't output ERROR level stacktrace in getLogger() call when there is no network available
[
https://issues.apache.org/jira/browse/LOG4J2-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Louis Bergelson updated LOG4J2-3602:
Description:
If there is no network adaptor trying to get a new logger using
`LogManager.getLogger()` results in an ERROR level log message with a full
stacktrace. This seems unintentional and undesirable.
Here's an example of the output:
{quote}ERROR Could not determine local host name java.net.UnknownHostException:
de2c81c88ddc: de2c81c88ddc: Temporary failure in name resolution
at java.net.InetAddress.getLocalHost(InetAddress.java:1506)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:620)
at
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:620)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)
at org.broadinstitute.hellbender.utils.Utils.(Utils.java:72)
at org.broadinstitute.hellbender.Main.(Main.java:45)
Caused by: java.net.UnknownHostException: de2c81c88ddc: Temporary failure in
name resolution
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
at java.net.InetAddress.getLocalHost(InetAddress.java:1501)
...13 more
{quote}
I believe this is unintentional because the associated code has a general
catch for all potential exceptions which logs a DEBUG level message in case of
failure. However the call to `NetUtils.getLocalHostname()` actually does it's
own error handling and very verbose logging.
The relevant call is here at LoggerContext.java line 613
{{try {}}
{{ map.computeIfAbsent("hostName", s -> NetUtils.getLocalHostname());}}
{{} catch (final Exception ex) {}}
{{ LOGGER.debug("Ignoring {}, setting hostName to 'unknown'",
ex.toString());}}
{{ map.putIfAbsent("hostName", "unknown");}}
{{}}}
The problematic logging statement is in NetUtils.getLocalHostname() line 77:
{{} catch (final UnknownHostException uhe) {}}
{{ ...}}
{{ LOGGER.error("Could not determine local host name", uhe);}}
{{ return UNKNOWN_LOCALHOST;}}
{{}}}
was:
If there is no network adaptor trying to get a new logger using
`LogManager.getLogger()` results in an ERROR level log message with a full
stacktrace. This seems unintentional and undesirable.
Here's an example of the output:
{quote}ERROR Could not determine local host name java.net.UnknownHostException:
de2c81c88ddc: de2c81c88ddc: Temporary failure in name resolution
at java.net.InetAddress.getLocalHost(InetAddress.java:1506)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:620)
at
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:620)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)
at org.broadinstitute.hellbender.utils.Utils.(Utils.java:72)
at org.broadinstitute.hellbender.Main.(Main.java:45)
Caused by: java.net.UnknownHostException: de2c81c88ddc: Temporary failure in
name resolution
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
at java.net.InetAddress.getLocalHost(InetAddress.java:1501)
...13 more
{quote}
I believe this is unintentional because the associated code has a general
catch for all potential exceptions which logs a DEBUG level message in case of
failure. However the
[jira] [Created] (LOG4J2-3602) Don't output ERROR level stacktrace in getLogger() call when there is no network available
Louis Bergelson created LOG4J2-3602:
---
Summary: Don't output ERROR level stacktrace in getLogger() call
when there is no network available
Key: LOG4J2-3602
URL: https://issues.apache.org/jira/browse/LOG4J2-3602
Project: Log4j 2
Issue Type: Improvement
Components: Core
Affects Versions: 2.17.2, 2.17.1
Environment: In this case software was running in a docker container
with localhost `–network none` set.
Reporter: Louis Bergelson
If there is no network adaptor trying to get a new logger using
`LogManager.getLogger()` results in an ERROR level log message with a full
stacktrace. This seems unintentional and undesirable.
Here's an example of the output:
{quote}ERROR Could not determine local host name java.net.UnknownHostException:
de2c81c88ddc: de2c81c88ddc: Temporary failure in name resolution
at java.net.InetAddress.getLocalHost(InetAddress.java:1506)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:620)
at
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:620)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)
at org.broadinstitute.hellbender.utils.Utils.(Utils.java:72)
at org.broadinstitute.hellbender.Main.(Main.java:45)
Caused by: java.net.UnknownHostException: de2c81c88ddc: Temporary failure in
name resolution
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
at java.net.InetAddress.getLocalHost(InetAddress.java:1501)
...13 more
{quote}
I believe this is unintentional because the associated code has a general
catch for all potential exceptions which logs a DEBUG level message in case of
failure. However the call to `NetUtils.getLocalHostname()` actually does it's
own error handling and very verbose logging.
The relevant call is here at LoggerContext.java line 613
{{try {}}
{{ map.computeIfAbsent("hostName", s -> NetUtils.getLocalHostname());}}
{{} catch (final Exception ex) {}}
{{ LOGGER.debug("Ignoring {}, setting hostName to 'unknown'",
ex.toString());}}
{{ map.putIfAbsent("hostName", "unknown");}}
{{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606750#comment-17606750
]
Christopher Tubbs commented on LOG4J2-3601:
---
[~pkarwasz] It does not make sense to use log4j-slf4j2-impl as the slf4j
binding, then to put in something other than log4j-core. That's not how users
use this dependency. The whole point in using the log4j-slf4j2-impl binding (or
the log4j-slf4j-impl binding for slf4j 1.7) is that the user wants slf4j logs
to go to log4j. If they wanted a different runtime, they wouldn't use this
jar... they'd use a different slf4j binding directly to that implementation.
The whole point is that users use these impl bindings to get logs sent to
log4j-core. It should not be optional.
Another reason why it doesn't make sense to make it optional, is that it is
inconsistent with how log4j-slf4j-impl and log4j-slf4j18-impl were configured.
log4j-slf4j2-impl should behave the same way log4j-slf4j-impl does, with
log4j-core as a runtime dependency. They should be consistent. Having
log4j-slf4j-impl and log4j-slf4j18-impl have a runtime dependency on log4j-core
was never a problem. It should not be a problem to have log4j-sfl4j2-impl
behave the same.
Marking the dependency as "optional" isn't a solution... it's just enshrining
the bug being reported here. Users can already explicitly add log4j-core as a
dependency, so it's effectively already optional. The point is that they
shouldn't have to, just like they don't have to with log4j-slf4j-impl.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606725#comment-17606725
]
Piotr Karwasz commented on LOG4J2-3601:
---
[~andy],
Thank you for reporting this issue.
Personally I am not sure it is a problem, since Log4j2 Core is not the only
Log4j2 API implementation out there (even if we exclude Log4j2-to-Slf4j). Would
an *optional* runtime dependency on {{log4j-core}} be a solution? [~rgoers],
what do you think?
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606714#comment-17606714
]
Ralph Goers commented on LOG4J2-3601:
-
Note that we don't assign fix versions until the fix is committed.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers updated LOG4J2-3601:
Affects Version/s: 2.19.0
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Affects Versions: 2.19.0
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers updated LOG4J2-3601:
Fix Version/s: (was: 2.19.0)
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606713#comment-17606713
]
Christopher Tubbs commented on LOG4J2-3601:
---
FWIW, the fix version is incorrect. 2.19.0 is already released without this
fix. 2.19.0 is the affected version, and 2.19.1 should be the fix version.
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606710#comment-17606710
]
Christopher Tubbs edited comment on LOG4J2-3601 at 9/19/22 6:37 PM:
This bit us when we tried to update to slf4j 2.0.1 with log4j-slf4j2-impl in
Apache Accumulo at https://github.com/apache/accumulo/pull/2942
See this partial diff comparing log4j-slf4j-impl and the new log4j-slf4j2-impl.
Their dependency on log4j-core should be the same: runtime.
{code}
---
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.19.0/log4j-slf4j-impl-2.19.0.pom
2022-09-19 14:20:09.033906470 -0400
+++
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j2-impl/2.19.0/log4j-slf4j2-impl-2.19.0.pom
2022-09-18 20:50:31.103647811 -0400
@@ -23,15 +23,13 @@
2.19.0
- log4j-slf4j-impl
+ log4j-slf4j2-impl
jar
- Apache Log4j SLF4J Binding
- The Apache Log4j SLF4J API binding to Log4j 2 Core
+ Apache Log4j SLF4J 2.0 Binding
+ The Apache Log4j SLF4J 2.0 API binding to Log4j 2
Core
${basedir}/..
SLF4J Documentation
-/slf4j-impl
-
-1.7.25
+/slf4j2-impl
+2.0.0
org.apache.logging.log4j.slf4j
true
@@ -56,5 +54,5 @@
org.apache.logging.log4j
log4j-core
- runtime
+ test
{code}
was (Author: ctubbsii):
This bit us when we tried to update to slf4j 2.0.1 with log4j-slf4j2-impl.
See this partial diff comparing log4j-slf4j-impl and the new log4j-slf4j2-impl.
Their dependency on log4j-core should be the same: runtime.
{code}
---
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.19.0/log4j-slf4j-impl-2.19.0.pom
2022-09-19 14:20:09.033906470 -0400
+++
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j2-impl/2.19.0/log4j-slf4j2-impl-2.19.0.pom
2022-09-18 20:50:31.103647811 -0400
@@ -23,15 +23,13 @@
2.19.0
- log4j-slf4j-impl
+ log4j-slf4j2-impl
jar
- Apache Log4j SLF4J Binding
- The Apache Log4j SLF4J API binding to Log4j 2 Core
+ Apache Log4j SLF4J 2.0 Binding
+ The Apache Log4j SLF4J 2.0 API binding to Log4j 2
Core
${basedir}/..
SLF4J Documentation
-/slf4j-impl
-
-1.7.25
+/slf4j2-impl
+2.0.0
org.apache.logging.log4j.slf4j
true
@@ -56,5 +54,5 @@
org.apache.logging.log4j
log4j-core
- runtime
+ test
{code}
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606710#comment-17606710
]
Christopher Tubbs commented on LOG4J2-3601:
---
This bit us when we tried to update to slf4j 2.0.1 with log4j-slf4j2-impl.
See this partial diff comparing log4j-slf4j-impl and the new log4j-slf4j2-impl.
Their dependency on log4j-core should be the same: runtime.
{code}
---
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.19.0/log4j-slf4j-impl-2.19.0.pom
2022-09-19 14:20:09.033906470 -0400
+++
~/.m2/repository/org/apache/logging/log4j/log4j-slf4j2-impl/2.19.0/log4j-slf4j2-impl-2.19.0.pom
2022-09-18 20:50:31.103647811 -0400
@@ -23,15 +23,13 @@
2.19.0
- log4j-slf4j-impl
+ log4j-slf4j2-impl
jar
- Apache Log4j SLF4J Binding
- The Apache Log4j SLF4J API binding to Log4j 2 Core
+ Apache Log4j SLF4J 2.0 Binding
+ The Apache Log4j SLF4J 2.0 API binding to Log4j 2
Core
${basedir}/..
SLF4J Documentation
-/slf4j-impl
-
-1.7.25
+/slf4j2-impl
+2.0.0
org.apache.logging.log4j.slf4j
true
@@ -56,5 +54,5 @@
org.apache.logging.log4j
log4j-core
- runtime
+ test
{code}
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [logging-log4cxx] rm5248 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
rm5248 commented on code in PR #132: URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974279067 ## src/main/include/log4cxx/hierarchy.h: ## @@ -66,15 +66,10 @@ class LOG4CXX_EXPORT Hierarchy : LOG4CXX_CAST_ENTRY(spi::LoggerRepository) END_LOG4CXX_CAST_MAP() - private: - /** - Create a new logger hierarchy. - */ - Hierarchy(); - public: static HierarchyPtr create(); + Hierarchy(); Review Comment: Since there's already a `create` method, this doesn't need to be public - I think this should be a singleton anyway. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] rm5248 commented on a diff in pull request #132: Use std::make_shared to create std::shared_ptr instances
rm5248 commented on code in PR #132:
URL: https://github.com/apache/logging-log4cxx/pull/132#discussion_r974276552
##
src/main/include/log4cxx/helpers/threadutility.h:
##
@@ -69,15 +69,14 @@ LOG4CXX_PTR_DEF(ThreadUtility);
class LOG4CXX_EXPORT ThreadUtility
{
private:
- ThreadUtility();
-
log4cxx::helpers::ThreadStartPre preStartFunction();
log4cxx::helpers::ThreadStarted threadStartedFunction();
log4cxx::helpers::ThreadStartPost postStartFunction();
LOG4CXX_DECLARE_PRIVATE_MEMBER_PTR(priv_data, m_priv)
public:
+ ThreadUtility();
Review Comment:
It seems like this would break the singleton aspect of this class, do we
really want it to have a public constructor?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] closed pull request #1057: Bump github/codeql-action from 2.1.22 to 2.1.23
dependabot[bot] closed pull request #1057: Bump github/codeql-action from 2.1.22 to 2.1.23 URL: https://github.com/apache/logging-log4j2/pull/1057 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request, #1068: Bump github/codeql-action from 2.1.22 to 2.1.24
dependabot[bot] opened a new pull request, #1068: URL: https://github.com/apache/logging-log4j2/pull/1068 Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.1.22 to 2.1.24. Changelog Sourced from https://github.com/github/codeql-action/blob/main/CHANGELOG.md";>github/codeql-action's changelog. CodeQL Action Changelog [UNRELEASED] We will soon be rolling out a feature of the CodeQL Action that stores some information used to make future runs faster in the GitHub Actions cache. Initially, this will only be enabled on JavaScript repositories, but we plan to add more languages to this soon. The new feature can be disabled by passing the trap-caching: false option to your workflow's init step, for example if you are already using the GitHub Actions cache for a different purpose and are near the storage limit for it. 2.1.24 - 16 Sep 2022 No user facing changes. 2.1.23 - 14 Sep 2022 Allow CodeQL packs to be downloaded from GitHub Enterprise Server instances, using the new registries input for the init action. https://github-redirect.dependabot.com/github/codeql-action/pull/1221";>#1221 Update default CodeQL bundle version to 2.10.5. https://github-redirect.dependabot.com/github/codeql-action/pull/1240";>#1240 2.1.22 - 01 Sep 2022 Downloading CodeQL packs has been moved to the init step. Previously, CodeQL packs were downloaded during the analyze step. https://github-redirect.dependabot.com/github/codeql-action/pull/1218";>#1218 Update default CodeQL bundle version to 2.10.4. https://github-redirect.dependabot.com/github/codeql-action/pull/1224";>#1224 The newly released https://python-poetry.org/blog/announcing-poetry-1.2.0";>Poetry 1.2 is not yet supported. In the most common case where the CodeQL Action is automatically installing Python dependencies, it will continue to install and use Poetry 1.1 on its own. However, in certain cases such as with self-hosted runners, you may need to ensure Poetry 1.1 is installed yourself. 2.1.21 - 25 Aug 2022 Improve error messages when the code scanning configuration file includes an invalid queries block or an invalid query-filters block. https://github-redirect.dependabot.com/github/codeql-action/pull/1208";>#1208 Fix a bug where Go build tracing could fail on Windows. https://github-redirect.dependabot.com/github/codeql-action/pull/1209";>#1209 2.1.20 - 22 Aug 2022 No user facing changes. 2.1.19 - 17 Aug 2022 Add the ability to filter queries from a code scanning run by using the query-filters option in the code scanning configuration file. https://github-redirect.dependabot.com/github/codeql-action/pull/1098";>#1098 In debug mode, debug artifacts are now uploaded even if a step in the Actions workflow fails. https://github-redirect.dependabot.com/github/codeql-action/pull/1159";>#1159 Update default CodeQL bundle version to 2.10.3. https://github-redirect.dependabot.com/github/codeql-action/pull/1178";>#1178 The combination of python2 and Pipenv is no longer supported. https://github-redirect.dependabot.com/github/codeql-action/pull/1181";>#1181 2.1.18 - 03 Aug 2022 Update default CodeQL bundle version to 2.10.2. https://github-redirect.dependabot.com/github/codeql-action/pull/1156";>#1156 2.1.17 - 28 Jul 2022 Update default CodeQL bundle version to 2.10.1. https://github-redirect.dependabot.com/github/codeql-action/pull/1143";>#1143 2.1.16 - 13 Jul 2022 You can now quickly debug a job that uses the CodeQL Action by re-running the job from the GitHub UI and selecting the "Enable debug logging" option. https://github-redirect.dependabot.com/github/codeql-action/pull/1132";>#1132 You can now see diagnostic messages produced by the analysis in the logs of the analyze Action by enabling debug mode. To enable debug mode, pass debug: true to the init Action, or https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging";>enable step debug logging. This feature is available for CodeQL CLI version 2.10.0 and later. https://github-redirect.dependabot.com/github/codeql-action/pull/1133";>#1133 ... (truncated) Commits https://github.com/github/codeql-action/commit/904260d7d935dff982205cbdb42025ce30b7a34f";>904260d Merge pull request https://github-redirect.dependabot.com/github/codeql-action/issues/1250";>#1250 from github/update-v2.1.24-34aa5a55 https://github.com/github/codeql-action/commit/21c716dd69ad10ce1b62c4be6ff2833875d62e36";>21c716d Update changelog for v2.1.24 https://github.com/github/codeql-action/commit/34aa5a554b0823e362370e66cd80ed0875e304c1";>34aa5a5 Merge pull request https://github-redirect.dependabot.com/github/codeql-action/issues/1242";>#1242 from github/henrymercer/go-more-backwards-compat https://github.com/github/codeql-action
[GitHub] [logging-log4j2] dependabot[bot] commented on pull request #1057: Bump github/codeql-action from 2.1.22 to 2.1.23
dependabot[bot] commented on PR #1057: URL: https://github.com/apache/logging-log4j2/pull/1057#issuecomment-1250855995 Superseded by #1068. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated LOG4J2-3601:
--
Description:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
{{log4j-slf4j18-impl}} similarly had scope=runtime.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Apache Jena) use slf4j in the main code base, and select log4j
when it needed for binaries tests so we have multiple places where the
dependency happens. We can change - but this may be a user experience for
others as well.
{noformat}
[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
[INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
{noformat}
{noformat}
[INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
[INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
{noformat}
was:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Jena) use slf4j in the main code base and include log4j for tests:
{noformat}
[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
[INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
{noformat}
{noformat}
{noformat}
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core. {{log4j-slf4j18-impl}} similarly had scope=runtime.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Apache Jena) use slf4j in the main code base, and select log4j
> when it needed for binaries tests so we have multiple places where the
> dependency happens. We can change - but this may be a user experience for
> others as well.
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated LOG4J2-3601:
--
Description:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Jena) use slf4j in the main code base and include log4j for tests:
{noformat}
[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
[INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
[INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
{noformat}
{noformat}
{noformat}
was:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Jena) use slf4j in the main code base and include log4j for tests:
{noformat}
{noformat}
{noformat}
[INFO] \- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:test
[INFO]\- org.apache.logging.log4j:log4j-api:jar:2.19.0:test
{noformat}
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Jena) use slf4j in the main code base and include log4j for
> tests:
> {noformat}
> [INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.18.0:compile
> [INFO] | +- org.apache.logging.log4j:log4j-api:jar:2.18.0:compile
> [INFO] | \- org.apache.logging.log4j:log4j-core:jar:2.18.0:runtime
> {noformat}
> {noformat}
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3601) log4j-slf4j2: change of dependency scope for log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated LOG4J2-3601:
--
Description:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Jena) use slf4j in the main code base and include log4j for tests:
{noformat}
{noformat}
{noformat}
[INFO] \- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:test
[INFO]\- org.apache.logging.log4j:log4j-api:jar:2.19.0:test
{noformat}
was:
The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on log4j-core.
The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
This changed as part of [commit
8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
although it seems to be unrelated.
It makes switching over more of a bump. Previously just depending on
{{log4j-slf4j-impl}} was enough.
Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
Example: we (Jena) use slf4j in the main code base and include log4j for tests:
{noformat}
[INFO] \- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.19.0:test
[INFO]+- org.apache.logging.log4j:log4j-api:jar:2.19.0:test
[INFO]\- org.apache.logging.log4j:log4j-core:jar:2.19.0:test
{noformat}
{noformat}
[INFO] \- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:test
[INFO]\- org.apache.logging.log4j:log4j-api:jar:2.19.0:test
{noformat}
> log4j-slf4j2: change of dependency scope for log4j-core
> ---
>
> Key: LOG4J2-3601
> URL: https://issues.apache.org/jira/browse/LOG4J2-3601
> Project: Log4j 2
> Issue Type: Improvement
> Components: SLF4J Bridge
>Reporter: Andy Seaborne
>Priority: Major
> Fix For: 2.19.0
>
>
> The artifact {{log4j-slf4j-impl}} has a scope=runtime dependency on
> log4j-core.
> The artifact {{log4j-slf4j2-impl}} has a scope=test dependency on log4j-core.
> This changed as part of [commit
> 8f63620875|https://github.com/apache/logging-log4j2/pull/1024/files#diff-d3ba9956a9f81420d0be3d69477a05b505746272d548ab17404aa47f3e5946b0]
> although it seems to be unrelated.
> It makes switching over more of a bump. Previously just depending on
> {{log4j-slf4j-impl}} was enough.
> Please switch back to a scope=runtime dependency for {{log4j-slf4j2-impl}}.
> Example: we (Jena) use slf4j in the main code base and include log4j for
> tests:
> {noformat}
> {noformat}
> {noformat}
> [INFO] \- org.apache.logging.log4j:log4j-slf4j2-impl:jar:2.19.0:test
> [INFO]\- org.apache.logging.log4j:log4j-api:jar:2.19.0:test
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [logging-log4j2] dependabot[bot] closed pull request #928: Bump apache-rat-plugin from 0.13 to 0.14
dependabot[bot] closed pull request #928: Bump apache-rat-plugin from 0.13 to 0.14 URL: https://github.com/apache/logging-log4j2/pull/928 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] commented on pull request #928: Bump apache-rat-plugin from 0.13 to 0.14
dependabot[bot] commented on PR #928: URL: https://github.com/apache/logging-log4j2/pull/928#issuecomment-1250819543 Superseded by #1067. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request, #1067: Bump apache-rat-plugin from 0.13 to 0.15
dependabot[bot] opened a new pull request, #1067: URL: https://github.com/apache/logging-log4j2/pull/1067 Bumps apache-rat-plugin from 0.13 to 0.15. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] closed pull request #979: Bump groovy.version from 3.0.10 to 3.0.12
dependabot[bot] closed pull request #979: Bump groovy.version from 3.0.10 to 3.0.12 URL: https://github.com/apache/logging-log4j2/pull/979 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] commented on pull request #979: Bump groovy.version from 3.0.10 to 3.0.12
dependabot[bot] commented on PR #979: URL: https://github.com/apache/logging-log4j2/pull/979#issuecomment-1250817193 Superseded by #1066. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request, #1066: Bump groovy.version from 3.0.10 to 3.0.13
dependabot[bot] opened a new pull request, #1066: URL: https://github.com/apache/logging-log4j2/pull/1066 Bumps `groovy.version` from 3.0.10 to 3.0.13. Updates `groovy-jsr223` from 3.0.10 to 3.0.13 Commits See full diff in https://github.com/apache/groovy/commits";>compare view Updates `groovy-dateutil` from 3.0.10 to 3.0.13 Commits See full diff in https://github.com/apache/groovy/commits";>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request, #1065: Bump kafka-clients from 1.1.1 to 3.2.3
dependabot[bot] opened a new pull request, #1065: URL: https://github.com/apache/logging-log4j2/pull/1065 Bumps kafka-clients from 1.1.1 to 3.2.3. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] closed pull request #1047: Bump kafka-clients from 1.1.1 to 3.2.2
dependabot[bot] closed pull request #1047: Bump kafka-clients from 1.1.1 to 3.2.2 URL: https://github.com/apache/logging-log4j2/pull/1047 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dependabot[bot] commented on pull request #1047: Bump kafka-clients from 1.1.1 to 3.2.2
dependabot[bot] commented on PR #1047: URL: https://github.com/apache/logging-log4j2/pull/1047#issuecomment-1250815795 Superseded by #1065. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] swebb2066 opened a new pull request, #132: Use std::make_shared to create std::shared_ptr instances
swebb2066 opened a new pull request, #132: URL: https://github.com/apache/logging-log4cxx/pull/132 This is a performance improvement as std::make_shared makes only one allocation. Some previously private constructors have been made public as std::make_shared needs access to the constructor. While these constructors are not intended for client use, [alternative](https://stackoverflow.com/questions/8147027/how-do-i-call-stdmake-shared-on-a-class-with-only-protected-or-private-const) approaches seem unnessessaryly complex. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
