[jira] [Resolved] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz resolved LOG4J2-3419.
---
Fix Version/s: 2.17.3
Resolution: Fixed
[~TukeshK], [~ragini]: I have generated a new snapshot of version 2.17.3. Can
you check if this solves your problem?
Custom Log4j 1.x levels should work out-of-the-box (like {{UtilLoggingLevel}}).
On the other hand, if you want to use a custom Log4j 2.x level in the Log4j 1.x
configuration file you must:
# Take care to declare the level *before* the configuration is read,
# Use the {{level_name#org.apache.logging.log4j.Level}} syntax in the
configuration file.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Fix For: 2.17.3
>
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505400#comment-17505400
]
ASF subversion and git services commented on LOG4J2-3419:
-
Commit 1a364ccfcc87f387967077a4c35448a06a0a7298 in logging-log4j2's branch
refs/heads/release-2.x from ppkarwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1a364cc ]
[LOG4J2-3419] Adds support for custom Log4j 1.x levels (#789)
* [LOG4J2-3419] Adds support for custom Log4j 1.x levels
Adds support for custom Log4j 1.x level in the form
`level_name#class_name`.
Levels defined directly in Log4j 2.x can be used in the bridge using the
form `level_name#org.apache.logging.log4j.Level`.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz merged pull request #789: [LOG4J2-3419] Adds support for custom Log4j 1.x levels
ppkarwasz merged pull request #789: URL: https://github.com/apache/logging-log4j2/pull/789 -- 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-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505376#comment-17505376
]
Gary D. Gregory commented on LOG4J2-3431:
-
[~TukeshK]
Note the solution in [https://github.com/apache/logging-log4j2/pull/789]
Will that work for your use case?
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505372#comment-17505372
]
Tukesh commented on LOG4J2-3419:
Yes, however "forName" method first checks if Level is already instantiated or
not. If it is not then only it create object of it. so all log4j 2-x native
levels must be already instantiated so int value of those will be unchanged.
{code:java}
Level.java :-
public static Level forName(final String name, final int intValue) {
final Level level = LEVELS.get(name);
if (level != null) {
return level;
}
try {
return new Level(name, intValue);
} catch (final IllegalStateException ex) {
// The level was added by something else so just return that one.
return LEVELS.get(name);
}
}{code}
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505370#comment-17505370
]
Tukesh commented on LOG4J2-3431:
Yes, however "forName" method first checks if Level is already instantiated or
not. If it is not then only it create object of it. so all log4j 2-x native
levels must be already instantiated so int value of those will be unchanged.
{code:java}
Level.java :-
public static Level forName(final String name, final int intValue) {
final Level level = LEVELS.get(name);
if (level != null) {
return level;
}
try {
return new Level(name, intValue);
} catch (final IllegalStateException ex) {
// The level was added by something else so just return that one.
return LEVELS.get(name);
}
}{code}
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
>
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505358#comment-17505358
]
Piotr Karwasz commented on LOG4J2-3419:
---
Hi [~TukeshK], the solution is a little bit more complex, since the numeric
levels of Log4j 1.x and Log4j 2.x are not equal. I will be merging [PR
#789|https://github.com/apache/logging-log4j2/pull/789] this weekend.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505357#comment-17505357
]
Tukesh edited comment on LOG4J2-3419 at 3/12/22, 8:58 PM:
--
[^DemoCustom.zip] demos how custom levels can be made working once following
method implementation is altered in OptionConverter.java in bridge API.
{code:java}
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
} {code}
Please note the bridge API jar in this ZIP is built after above code change is
done in local checkout.
was (Author: JIRAUSER282001):
[^DemoCustom.zip] demos how custom levels can be made working once following
method implementation is altered in OptionConverter.java in bridge API.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505357#comment-17505357
]
Tukesh commented on LOG4J2-3419:
[^DemoCustom.zip] demos how custom levels can be made working once following
method implementation is altered in OptionConverter.java in bridge API.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tukesh updated LOG4J2-3419:
---
Attachment: DemoCustom.zip
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505349#comment-17505349
]
Tukesh edited comment on LOG4J2-3419 at 3/12/22, 8:40 PM:
--
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering. In this programmer will have to
initialize custom levels in log4j2-x level using
org.apache.logging.log4j.Level.forName(,) method.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
was (Author: JIRAUSER282001):
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tukesh resolved LOG4J2-3431.
Resolution: Fixed
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tukesh resolved LOG4J2-3431.
Resolution: Duplicate
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tukesh reopened LOG4J2-3431:
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505356#comment-17505356
]
Tukesh commented on LOG4J2-3431:
Sorry, I mis-interpretted your comment. I have put my observations on linked
Jira too for your perpetual.
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505348#comment-17505348
]
Tukesh edited comment on LOG4J2-3431 at 3/12/22, 8:34 PM:
--
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
was (Author: JIRAUSER282001):
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering. I am assuming user has created log2-x
level objects of each log4j1-x custom levels using
"org.apache.logging.log4j.Level.forName()" as mentioned by Ragini in comments.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
>
[jira] [Comment Edited] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505349#comment-17505349
]
Tukesh edited comment on LOG4J2-3419 at 3/12/22, 8:33 PM:
--
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
was (Author: JIRAUSER282001):
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering. I am assuming user has created log2-x
level objects of each log4j1-x custom levels using
"org.apache.logging.log4j.Level.forName()" as mentioned by Ragini in comments.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505353#comment-17505353
]
Gary D. Gregory commented on LOG4J2-3431:
-
[~TukeshK] See the previous comment and
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505348#comment-17505348
]
Tukesh edited comment on LOG4J2-3431 at 3/12/22, 7:53 PM:
--
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering. I am assuming user has created log2-x
level objects of each log4j1-x custom levels using
"org.apache.logging.log4j.Level.forName()" as mentioned by Ragini in comments.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
was (Author: JIRAUSER282001):
Following implementation of convertLevel resolves the problem of custom levels
in bridge API.
public static org.apache.logging.log4j.Level convertLevel(final Level level) {
return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> retu
[jira] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[ https://issues.apache.org/jira/browse/LOG4J2-3431 ]
Tukesh deleted comment on LOG4J2-3431:
was (Author: JIRAUSER282001):
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
problems of custom levels.
public static org.apache.logging.log4j.Level convertLevel(final Level level) {
return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
Do you agree with this change ?
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505349#comment-17505349
]
Tukesh edited comment on LOG4J2-3419 at 3/12/22, 7:51 PM:
--
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
the problem of custom level/s filtering. I am assuming user has created log2-x
level objects of each log4j1-x custom levels using
"org.apache.logging.log4j.Level.forName()" as mentioned by Ragini in comments.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt()); }
Do you agree with this change ? If yes then can you please commit this change.
was (Author: JIRAUSER282001):
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
problems of custom levels.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
Do you agree with this change ? If yes then can you please commit this change.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505349#comment-17505349
]
Tukesh commented on LOG4J2-3419:
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
problems of custom levels.
public static org.apache.logging.log4j.Level convertLevel(final Level level)
{ return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
Do you agree with this change ? If yes then can you please commit this change.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tukesh reopened LOG4J2-3431:
Following implementation of convertLevel resolves the problem of custom levels
in bridge API.
public static org.apache.logging.log4j.Level convertLevel(final Level level) {
return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files
[
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505347#comment-17505347
]
Tukesh commented on LOG4J2-3431:
In OptionConverter.java
replacing convertLevel(final Level level) with following implementation solves
problems of custom levels.
public static org.apache.logging.log4j.Level convertLevel(final Level level) {
return
org.apache.logging.log4j.Level.forName(level.toString(),level.toInt());
}
Do you agree with this change ?
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
> Issue Type: Bug
> Environment: JDK 1.8
>
> -Dlog4j1.compatibility=true
> # log4j-1.2-api-2.17.2.jar
> # log4j-api-2.17.2.jar
> # log4j-core-2.17.2.jar
>
>
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and
> all messages are written into log files
>
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;
> import org.apache.log4j.helpers.UtilLoggingLevel;import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
>
> public static void main(String[] args)throws IOException,SQLException{
> System.out.println("I'm running...");
> while(true){
> System.out.println("I'm running...");
>
> log.info("Log4j-shell this is a info message");
>
> log.log(UtilLoggingLevel.INFO,"INFO");
> log.log(UtilLoggingLevel.FINE,"FINE");
> log.log(UtilLoggingLevel.FINER,"FINER");
> log.log(UtilLoggingLevel.FINEST,"FINEST");
> log.log(UtilLoggingLevel.CONFIG,"CONIG");
>
> try {
> TimeUnit.MILLISECONDS.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> } {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log
> log4j.appender.DMCC_TRACE_LOGGER.Append=true
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>
>
> +*Investigation :-*+
> convertLevel function from OptionConverter.java doesn't consider
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for
> UtilLoggingLevel classes.
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ?
> org.apache.logging.log4j.Level.ERROR :
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
> loggerConfig.setLevel(level);
> LOGGER.debug("Logger {} level set to {}", loggerName, level);
>
>
> OptionConverter.java :-
> public static org.apache.logging.log4j.Level convertLevel(final Level
> level) {
> if (level == null) {
> return org.apache.logging.log4j.Level.ERROR;
> }
> if (level.isGreaterOrEqual(Level.FATAL)) {
> return org.apache.logging.log4j.Level.FATAL;
> } else if (level.isGreaterOrEqual(Level.ERROR)) {
> return org.apache.logging.log4j.Level.ERROR;
> } else if (level.isGreaterOrEqual(Level.WARN)) {
> return org.apache.logging.log4j.Level.WARN;
> } else if (level.isGreaterOrEqual(Level.INFO)) {
> return org.apache.logging.log4j.Level.INFO;
> } else if (level.isGreaterOrEqual(Level.DEBUG)) {
> return org.apache.logging.log4j.Level.DEBUG;
> } else if (level.isGreaterOrEqual(Level.TRACE)) {
> return org.apache.logging.log4j.Level.TRACE;
> }
> return org.apache.logging.log4j.Level.ALL;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505330#comment-17505330 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 50b00d8c1ca25437dd572e90b88294b60d292fd3 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-scm-plugin-1.12.2 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=50b00d8 ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3 * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505332#comment-17505332
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 9d3f8364161cdbdea6ee41ba810b505c4a217b1a in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-scm-plugin-1.12.2
from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9d3f836 ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory #791
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505333#comment-17505333 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 2aa831e0fa499b37e58b3588f3f78afe9a585b52 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-scm-plugin-1.12.2 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=2aa831e ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3. > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed
[
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505329#comment-17505329
]
ASF subversion and git services commented on LOG4J2-3423:
-
Commit de4e5dd1a902469cd6b3e5a5975af0d7eb4647e8 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-scm-plugin-1.12.2
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=de4e5dd ]
[LOG4J2-3423] Refactoring of URLConnection code
Refactors the code to minimize the number of calls to `URLConnection`
methods.
> JAR file containing Log4j configuration isn't closed
>
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file
> (which is backed by the {{JarURLConnection}} retrieved from
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}}
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is
> to use the {{URL.openConnection}} only when needed (~ configuration URL has
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3)
> would be used.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505325#comment-17505325 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 50b00d8c1ca25437dd572e90b88294b60d292fd3 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-project-info-reports-plugin-3.2.2 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=50b00d8 ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3 * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505327#comment-17505327
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 9d3f8364161cdbdea6ee41ba810b505c4a217b1a in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-project-info-reports-plugin-3.2.2
from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9d3f836 ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory #791
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed
[
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505324#comment-17505324
]
ASF subversion and git services commented on LOG4J2-3423:
-
Commit de4e5dd1a902469cd6b3e5a5975af0d7eb4647e8 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-project-info-reports-plugin-3.2.2
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=de4e5dd ]
[LOG4J2-3423] Refactoring of URLConnection code
Refactors the code to minimize the number of calls to `URLConnection`
methods.
> JAR file containing Log4j configuration isn't closed
>
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file
> (which is backed by the {{JarURLConnection}} retrieved from
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}}
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is
> to use the {{URL.openConnection}} only when needed (~ configuration URL has
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3)
> would be used.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505331#comment-17505331
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 67ba1fe05951e20cb9c29b47a1b1e8a6d8e2e181 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-scm-plugin-1.12.2
from Grzegorz Grzybek
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=67ba1fe ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory (#791)
Signed-off-by: Grzegorz Grzybek
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505328#comment-17505328 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 2aa831e0fa499b37e58b3588f3f78afe9a585b52 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-project-info-reports-plugin-3.2.2 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=2aa831e ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3. > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505326#comment-17505326
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 67ba1fe05951e20cb9c29b47a1b1e8a6d8e2e181 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-project-info-reports-plugin-3.2.2
from Grzegorz Grzybek
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=67ba1fe ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory (#791)
Signed-off-by: Grzegorz Grzybek
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505323#comment-17505323 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 2aa831e0fa499b37e58b3588f3f78afe9a585b52 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.4 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=2aa831e ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3. > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505322#comment-17505322
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 9d3f8364161cdbdea6ee41ba810b505c4a217b1a in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.4 from
Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9d3f836 ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory #791
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505320#comment-17505320 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 50b00d8c1ca25437dd572e90b88294b60d292fd3 in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.4 from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=50b00d8 ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3 * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed
[
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505319#comment-17505319
]
ASF subversion and git services commented on LOG4J2-3423:
-
Commit de4e5dd1a902469cd6b3e5a5975af0d7eb4647e8 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.4 from
Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=de4e5dd ]
[LOG4J2-3423] Refactoring of URLConnection code
Refactors the code to minimize the number of calls to `URLConnection`
methods.
> JAR file containing Log4j configuration isn't closed
>
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file
> (which is backed by the {{JarURLConnection}} retrieved from
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}}
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is
> to use the {{URL.openConnection}} only when needed (~ configuration URL has
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3)
> would be used.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505321#comment-17505321
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 67ba1fe05951e20cb9c29b47a1b1e8a6d8e2e181 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.4 from
Grzegorz Grzybek
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=67ba1fe ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory (#791)
Signed-off-by: Grzegorz Grzybek
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory commented on pull request #778: Bump maven-scm-plugin from 1.9.5 to 1.12.2
garydgregory commented on pull request #778: URL: https://github.com/apache/logging-log4j2/pull/778#issuecomment-1065940403 @dependabot rebase -- 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] garydgregory commented on pull request #779: Bump maven-project-info-reports-plugin from 2.9 to 3.2.2
garydgregory commented on pull request #779: URL: https://github.com/apache/logging-log4j2/pull/779#issuecomment-1065940368 @dependabot rebase -- 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] garydgregory commented on pull request #754: Bump maven-bundle-plugin from 3.5.0 to 5.1.4
garydgregory commented on pull request #754: URL: https://github.com/apache/logging-log4j2/pull/754#issuecomment-1065940339 @dependabot rebase -- 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] garydgregory merged pull request #792: Fix minor typo
garydgregory merged pull request #792: URL: https://github.com/apache/logging-log4j2/pull/792 -- 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] ppkarwasz commented on a change in pull request #789: [LOG4J2-3419] Adds support for custom Log4j 1.x levels
ppkarwasz commented on a change in pull request #789:
URL: https://github.com/apache/logging-log4j2/pull/789#discussion_r825309484
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/xml/XmlConfiguration.java
##
@@ -675,24 +675,13 @@ private void parseLevel(Element element, LoggerConfig
logger, boolean isRoot) {
}
} else {
String className = subst(element.getAttribute(CLASS_ATTR));
+final Level level;
if (EMPTY_STR.equals(className)) {
-logger.setLevel(OptionConverter.convertLevel(priStr,
org.apache.logging.log4j.Level.DEBUG));
+level = OptionConverter.toLevel(priStr, Level.DEBUG);
Review comment:
I'll look into that. There are actually two levels used throughout the
code: `Level.DEBUG` in places where we expect an operation to fail and
`Level.ERROR` where a conversion failure is unexpected (like in the
`convertLevel` methods).
--
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-3428) Update 3rd party dependencies for 2.17.3
[ https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505269#comment-17505269 ] ASF subversion and git services commented on LOG4J2-3428: - Commit 2aa831e0fa499b37e58b3588f3f78afe9a585b52 in logging-log4j2's branch refs/heads/release-2.x from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=2aa831e ] [LOG4J2-3428] Update 3rd party dependencies for 2.17.3. > Update 3rd party dependencies for 2.17.3 > > > Key: LOG4J2-3428 > URL: https://issues.apache.org/jira/browse/LOG4J2-3428 > Project: Log4j 2 > Issue Type: Task > Components: Build >Reporter: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > This ticket should only be closed when we release 2.17.3. > The updated dependencies are: > * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2 > * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> > 2.13.2 > * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre > * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3 > * org.awaitility:awaitility 4.1.1 -> 4.2.0 > * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10 > * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10 > * org.springframework:spring-aop 5.3.15 -> 5.3.16 > * org.springframework:spring-beans 5.3.15 -> 5.3.16 > * org.springframework:spring-context 5.3.15 -> 5.3.16 > * org.springframework:spring-context-support 5.3.15 -> 5.3.16 > * org.springframework:spring-core 5.3.15 -> 5.3.16 > * org.springframework:spring-expression 5.3.15 -> 5.3.16 > * org.springframework:spring-oxm 5.3.15 -> 5.3.16 > * org.springframework:spring-test 5.3.15 -> 5.3.16 > * org.springframework:spring-web 5.3.15 -> 5.3.16 > * org.springframework:spring-webmvc 5.3.15 -> 5.3.16 > * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0 > * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505267#comment-17505267
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 9d3f8364161cdbdea6ee41ba810b505c4a217b1a in logging-log4j2's branch
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9d3f836 ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory #791
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3040) ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
[
https://issues.apache.org/jira/browse/LOG4J2-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505265#comment-17505265
]
ASF subversion and git services commented on LOG4J2-3040:
-
Commit 67ba1fe05951e20cb9c29b47a1b1e8a6d8e2e181 in logging-log4j2's branch
refs/heads/release-2.x from Grzegorz Grzybek
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=67ba1fe ]
[LOG4J2-3040] Avoid ClassCastException in JeroMqManager with custom
LoggerContextFactory (#791)
Signed-off-by: Grzegorz Grzybek
> ShutdownCallbackRegistry should be part of log4j-api, not log4j-core
>
>
> Key: LOG4J2-3040
> URL: https://issues.apache.org/jira/browse/LOG4J2-3040
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working on https://github.com/ops4j/org.ops4j.pax.logging/issues/395
> related to Pax Logging project, which implements OSGi Log specification based
> on 3 _backends_:
> * Log4j1
> * Logback
> * Log4j2
> and several _frontends_:
> * Commons Logging
> * JULI Logging
> * javax.logging
> * SLF4J
> * Avalong
> * Log4j1 (API)
> * Log4j2 (API)
> * JBoss Logging
> Pax Logging implements own
> {{org.apache.logging.log4j.spi.LoggerContextFactory}}, where the
> {{org.apache.logging.log4j.spi.LoggerContext}} returned is managed by OSGi
> runtime (without using
> {{org.apache.logging.log4j.core.selector.ContextSelector}}).
> The problem is that several libraries assume that some casts are possible.
> There was an elasticsearch problem described
> [here|https://groups.google.com/g/ops4j/c/yjqOzvrKRkc/m/DZeUSdZeCAAJ], where
> level was set through configuration and
> {{org.apache.logging.log4j.core.LoggerContext#getContext(boolean)}}
> explicitly calls (in
> {{org.apache.logging.log4j.core.config.Configurator#setLevel()}}):
> {code:java}
> public static LoggerContext getContext(final boolean currentContext) {
> return (org.apache.logging.log4j.core.LoggerContext)
> LogManager.getContext(currentContext);
> }
> {code}
> assuming that {{org.apache.logging.log4j.LogManager#getContext(boolean)}}
> returns log4j-core specific implementation of the context.
> With https://github.com/ops4j/org.ops4j.pax.logging/issues/395 there's
> different problem.
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppender}} (part of
> log4j-core library) [long time
> ago|https://github.com/apache/logging-log4j2/commit/a6af67c5d6faee5b4d422add674e4c518c33d528]
> started to use
> {{org.apache.logging.log4j.core.util.ShutdownCallbackRegistry}} for cleanup.
> Now this is moved to
> {{org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager}}, but
> still there's this explicit code:
> {code:xml}
> if (enableShutdownHook) {
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> While normally, LogManager.getFactor() returns an instance of
> {{org.apache.logging.log4j.core.impl.Log4jContextFactory}}, it's *not*
> guaranteed by {{org.apache.logging.log4j.LogManager#getFactory}} API and
> indeed - pax-logging-api's implementation returns a factory that doesn't
> implement {{ShutdownCallbackRegistry}}.
> I tried two approaches:
> # _move_ (in OSGi terms) some packages from log4j-core to pax-logging-api
> (for now, pax-logging-api only operates on log4j-api), howver, transitively I
> ended up with almost entire log4j-core inside pax-logging-api
> # refactor log4j2 itself (locally) so {{ShutdownCallbackRegistry}} (and
> {{Cancellable}}) are part of {{org.apache.logging.log4j.spi}} package, but I
> ended with quite long list of errors from
> org.revapi:revapi-maven-plugin:0.11.1:check
> Mind that even
> {{org.apache.logging.log4j.core.LoggerContext#setUpShutdownHook()}} correctly
> checks for the interface to be implemented:
> {code:java}
> final LoggerContextFactory factory = LogManager.getFactory();
> if (factory instanceof ShutdownCallbackRegistry) {
> {code}
> It's *only* org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqManager
> that blindly calls:
> {code:java}
> SHUTDOWN_HOOK = ((ShutdownCallbackRegistry)
> LogManager.getFactory()).addShutdownCallback(CONTEXT::close);
> {code}
> Summarizing - ideally (IMO) {{ShutdownCallbackRegistry}} should be part of
> the API, but if it's not possible, please fix {{JeroMqManager}} to check for
> the implementation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory merged pull request #791: [LOG4J2-3040][2.x] Avoid ClassCastException in JeroMqManager with custom LoggerContextFactory
garydgregory merged pull request #791: URL: https://github.com/apache/logging-log4j2/pull/791 -- 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] garydgregory commented on a change in pull request #789: [LOG4J2-3419] Adds support for custom Log4j 1.x levels
garydgregory commented on a change in pull request #789:
URL: https://github.com/apache/logging-log4j2/pull/789#discussion_r825295699
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/xml/XmlConfiguration.java
##
@@ -675,24 +675,13 @@ private void parseLevel(Element element, LoggerConfig
logger, boolean isRoot) {
}
} else {
String className = subst(element.getAttribute(CLASS_ATTR));
+final Level level;
if (EMPTY_STR.equals(className)) {
-logger.setLevel(OptionConverter.convertLevel(priStr,
org.apache.logging.log4j.Level.DEBUG));
+level = OptionConverter.toLevel(priStr, Level.DEBUG);
Review comment:
THere are several places where we specify a default level (Level.DEBUG)
in this method and likely elsewhere. It would be nicer to have a default level
defined in a constant IMO; this would make it obvious that this is a "default"
as opposed to "in this case, we have level Foo". WDYT?
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/xml/XmlConfiguration.java
##
@@ -675,24 +675,13 @@ private void parseLevel(Element element, LoggerConfig
logger, boolean isRoot) {
}
} else {
String className = subst(element.getAttribute(CLASS_ATTR));
+final Level level;
if (EMPTY_STR.equals(className)) {
-logger.setLevel(OptionConverter.convertLevel(priStr,
org.apache.logging.log4j.Level.DEBUG));
+level = OptionConverter.toLevel(priStr, Level.DEBUG);
Review comment:
There are several places where we specify a default level (Level.DEBUG)
in this method and likely elsewhere. It would be nicer to have a default level
defined in a constant IMO; this would make it obvious that this is a "default"
as opposed to "in this case, we have level Foo". WDYT?
--
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
