[GitHub] [logging-log4j2] dfa1 commented on a change in pull request #770: Initial support for detached markers in SLF4J binding
dfa1 commented on a change in pull request #770:
URL: https://github.com/apache/logging-log4j2/pull/770#discussion_r828802299
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMarkerFactory.java
##
@@ -113,26 +125,19 @@ public boolean exists(final String name) {
return markerMap.containsKey(name);
}
-/**
- * Log4j does not support detached Markers. This method always returns
false.
- * @param name The Marker name.
- * @return {@code false}
- */
@Override
public boolean detachMarker(final String name) {
-return false;
+if (name == null) {
+return false;
+}
+detachedMarkers.add(name);
+return true;
}
-/**
- * Log4j does not support detached Markers for performance reasons. The
returned Marker is attached.
- * @param name The Marker name.
- * @return The named Marker (unmodified).
- */
@Override
public Marker getDetachedMarker(final String name) {
-LOGGER.warn("Log4j does not support detached Markers. Returned Marker
[{}] will be unchanged.", name);
-return getMarker(name);
+final org.apache.logging.log4j.Marker log4jMarker =
MarkerManager.getMarker(name);
Review comment:
@carterkozak thanks for the review! :)
Yes, this is exactly the point: *I tried to keep Log4j unaware of detached
markers*.
Since Log4j doesn't support detached markers, while SLF4J does, the proposed
implementation is wrapping a Lo4j's marker (that is cached internally as you
mentioned) with a fresh instance of SLF4J's marker.
Unless I'm missing something big, there are also few newly written unit
tests that can be used to disproof my understanding of the problem.
--
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] carterkozak commented on a change in pull request #770: Initial support for detached markers in SLF4J binding
carterkozak commented on a change in pull request #770:
URL: https://github.com/apache/logging-log4j2/pull/770#discussion_r828470138
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMarkerFactory.java
##
@@ -113,26 +125,19 @@ public boolean exists(final String name) {
return markerMap.containsKey(name);
}
-/**
- * Log4j does not support detached Markers. This method always returns
false.
- * @param name The Marker name.
- * @return {@code false}
- */
@Override
public boolean detachMarker(final String name) {
-return false;
+if (name == null) {
+return false;
+}
+detachedMarkers.add(name);
+return true;
}
-/**
- * Log4j does not support detached Markers for performance reasons. The
returned Marker is attached.
- * @param name The Marker name.
- * @return The named Marker (unmodified).
- */
@Override
public Marker getDetachedMarker(final String name) {
-LOGGER.warn("Log4j does not support detached Markers. Returned Marker
[{}] will be unchanged.", name);
-return getMarker(name);
+final org.apache.logging.log4j.Marker log4jMarker =
MarkerManager.getMarker(name);
Review comment:
This `MarkerManager.getMarker(name)` invocation causes the `name` to be
tracked in the `org.apache.logging.log4j.MarkerManager.MARKERS` collection, the
proposed change only avoids the slf4j adapters cache of markers converted into
the slf4j api.
For this to work, log4j2 would also need to be aware of detached markers,
which would also require changes to
`MarkerManager.Log4jMarker.isInstanceOf(Marker marker)` which currently does a
reference equality check rather than checking the string value.
--
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] dfa1 commented on pull request #770: Initial support for detached markers in SLF4J binding
dfa1 commented on pull request #770: URL: https://github.com/apache/logging-log4j2/pull/770#issuecomment-1069632985 @garydgregory hello 👋 would it be possible to have another look? 😊 Let me know how to improve this code to be included in a log4j release! -- 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-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507798#comment-17507798
]
Gary D. Gregory commented on LOG4J2-3437:
-
FTR, the method is {{org.apache.log4j.Category.addAppender(Appender)}}, the
superclass of Logger in 1.2.
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
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=17507675#comment-17507675
]
Piotr Karwasz commented on LOG4J2-3419:
---
[~ragini]: can you provide the code of your custom Log4j 1.x class? Every such
class must have a {{public static Level toLevel(String, Level)}} method.
> 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)
[GitHub] [logging-log4j2] garydgregory closed pull request #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
garydgregory closed pull request #800: URL: https://github.com/apache/logging-log4j2/pull/800 -- 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 #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
garydgregory commented on pull request #800: URL: https://github.com/apache/logging-log4j2/pull/800#issuecomment-1069217637 Closing, per @LF-Lin 's comment. TY! -- 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-3019) HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
[
https://issues.apache.org/jira/browse/LOG4J2-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507668#comment-17507668
]
Gary D. Gregory commented on LOG4J2-3019:
-
[~LKleeven] and all,
Please verify the release-2,x branch builds for you and close this ticket
builds for you.
TY!
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
> -
>
> Key: LOG4J2-3019
> URL: https://issues.apache.org/jira/browse/LOG4J2-3019
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: OS: Windows 10 Enterprise
> Version: 20H2
> OS Build: 19042.746
> Experience: Windows Feature Experience Pack 120.2212.551.0
> java version "1.8.0_192"
> Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
>Reporter: Luc Kleeven
>Assignee: Volkan Yazici
>Priority: Minor
> Fix For: 2.17.3
>
>
> When running a './mvnw verify' on the 'release-2.x' branche, last commit id
> '9788f33fc62b3b4012489a603772433d3440e6b0'. The following test fails:
> {code:java}
> [ERROR]
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
> Incorrect date=02 Nov 2012 21:34:02,123, format=DATE,
> timezone=GMT+8 ==> expected: <02 nov 2012 21:34:02,123> but was:
> <02 Nov 2012 21:34:02,123> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3019) HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
[
https://issues.apache.org/jira/browse/LOG4J2-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3019.
-
Fix Version/s: 2.17.3
Resolution: Fixed
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
> -
>
> Key: LOG4J2-3019
> URL: https://issues.apache.org/jira/browse/LOG4J2-3019
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: OS: Windows 10 Enterprise
> Version: 20H2
> OS Build: 19042.746
> Experience: Windows Feature Experience Pack 120.2212.551.0
> java version "1.8.0_192"
> Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
>Reporter: Luc Kleeven
>Assignee: Volkan Yazici
>Priority: Minor
> Fix For: 2.17.3
>
>
> When running a './mvnw verify' on the 'release-2.x' branche, last commit id
> '9788f33fc62b3b4012489a603772433d3440e6b0'. The following test fails:
> {code:java}
> [ERROR]
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
> Incorrect date=02 Nov 2012 21:34:02,123, format=DATE,
> timezone=GMT+8 ==> expected: <02 nov 2012 21:34:02,123> but was:
> <02 Nov 2012 21:34:02,123> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507652#comment-17507652 ] Pooja Pandey commented on LOG4J2-3437: -- Thank you so much Piotr for npe fix and detailed explanation on the solution to thread specific threshold. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507652#comment-17507652 ] Pooja Pandey edited comment on LOG4J2-3437 at 3/16/22, 2:22 PM: Thank you so much [~pkarwasz] for npe fix and detailed explanation on the solution to thread specific threshold. was (Author: JIRAUSER285751): Thank you so much Piotr for npe fix and detailed explanation on the solution to thread specific threshold. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507648#comment-17507648
]
Piotr Karwasz commented on LOG4J2-3437:
---
[~PoojaTheCoder], I fixed the NPE editing the comment above.
Regarding the complexity problems in your setup, the advise you got on the
{{log4j-user}} mailing list has been unanimous from day one: implement your
complex logic in native Log4j 2.x and use the bridge for the
{{org.apache.log4j.Logger}} -> {{org.apache.logging.log4j.Logger}} message
relay only.
Using Log4j 2.x directly to inject (native Log4j 2.x) {{{}FileAppender{}}}s
into the configuration will save you a lot of coding. What you are looking for
already exists in Log4j 2.x: it is called
[DynamicThresholdFilter|https://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter].
You can add it to the logger config above using the
{{LoggerConfig.Builder#withFilter}} method. IIRC you want {{onMatch=ACCEPT}}
and {{{}onMismatch=NEUTRAL{}}}.
It works by looking up a key in the [thread
context|https://logging.apache.org/log4j/2.x/manual/thread-context.html] (a
sort of {{{}ThreadLocal{}}}). If the key is absent, the configured logger
config level is used. If the key is present and the message is less specific
than the level associated to the key, the message is passed to the appender.
Otherwise the configured logger config level is checked.
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507544#comment-17507544
]
Piotr Karwasz edited comment on LOG4J2-3437 at 3/16/22, 1:50 PM:
-
[~PoojaTheCoder]: that API is not implemented (it is almost a no-op).
However you can do the same thing using native Log4j 2.x Core APIs:
{code:java}
final Logger logger = (Logger)
LogManager.getLogger("org.apache.logging.example");
final Configuration config = ((LoggerContext)
LogManager.getContext(false)).getConfiguration();
// FileAppender
final Appender appender = FileAppender.newBuilder()
.setConfiguration(config)
.setName("unique_name")
.withFileName("filename")
.build();
appender.start();
// 'threshold' can be translated in many ways, e.g. an AppenderRef level:
final LoggerConfig loggerConfig = LoggerConfig.newBuilder()
.withConfig(config)
.withLoggerName(logger.getName())
.withRefs(new AppenderRef[0])
.build();
loggerConfig.addAppender(appender, /*AppenderRef level*/ Level.DEBUG,
/*AppenderRef filter*/null);
config.addLogger(loggerConfig.getName(), loggerConfig);
{code}
Except {{LogManager}} and {{{}Level{}}}, all the classes above are from
{{{}org.apache.logging.log4j.core{}}}.
was (Author: pkarwasz):
[~PoojaTheCoder]: that API is not implemented (it is almost a no-op).
However you can do the same thing using native Log4j 2.x Core APIs:
{code:java}
final Logger logger = (Logger)
LogManager.getLogger("org.apache.logging.example");
final Configuration config = ((LoggerContext)
LogManager.getContext(false)).getConfiguration();
// FileAppender
final Appender appender = FileAppender.newBuilder()
.setConfiguration(config)
.setName("unique_name")
.withFileName("filename")
.build();
appender.start();
// 'threshold' can be translated in many ways, e.g. an AppenderRef level:
final LoggerConfig loggerConfig = LoggerConfig.newBuilder()
.withConfig(config)
.withLoggerName(logger.getName())
.build();
loggerConfig.addAppender(appender, /*AppenderRef level*/ Level.DEBUG,
/*AppenderRef filter*/null);
config.addLogger(loggerConfig.getName(), loggerConfig);
{code}
Except {{LogManager}} and {{Level}}, all the classes above are from
{{org.apache.logging.log4j.core}}.
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507544#comment-17507544
]
Piotr Karwasz edited comment on LOG4J2-3437 at 3/16/22, 1:50 PM:
-
[~PoojaTheCoder]: that API is not implemented (it is almost a no-op).
However you can do the same thing using native Log4j 2.x Core APIs:
{code:java}
final Logger logger = (Logger)
LogManager.getLogger("org.apache.logging.example");
final Configuration config = ((LoggerContext)
LogManager.getContext(false)).getConfiguration();
// FileAppender
final Appender appender = FileAppender.newBuilder()
.setConfiguration(config)
.setName("unique_name")
.withFileName("filename")
.build();
appender.start();
// 'threshold' can be translated in many ways, e.g. an AppenderRef level:
final LoggerConfig loggerConfig = LoggerConfig.newBuilder()
.withConfig(config)
.withLoggerName(logger.getName())
.withRefs(new AppenderRef[0])
.build();
loggerConfig.addAppender(appender, /*AppenderRef level*/ Level.DEBUG,
/*AppenderRef filter*/null);
config.addLogger(loggerConfig.getName(), loggerConfig);
{code}
Except {{LogManager}} and {{{}Level{}}}, all the classes above are from
{{{}org.apache.logging.log4j.core{}}}.
was (Author: pkarwasz):
[~PoojaTheCoder]: that API is not implemented (it is almost a no-op).
However you can do the same thing using native Log4j 2.x Core APIs:
{code:java}
final Logger logger = (Logger)
LogManager.getLogger("org.apache.logging.example");
final Configuration config = ((LoggerContext)
LogManager.getContext(false)).getConfiguration();
// FileAppender
final Appender appender = FileAppender.newBuilder()
.setConfiguration(config)
.setName("unique_name")
.withFileName("filename")
.build();
appender.start();
// 'threshold' can be translated in many ways, e.g. an AppenderRef level:
final LoggerConfig loggerConfig = LoggerConfig.newBuilder()
.withConfig(config)
.withLoggerName(logger.getName())
.withRefs(new AppenderRef[0])
.build();
loggerConfig.addAppender(appender, /*AppenderRef level*/ Level.DEBUG,
/*AppenderRef filter*/null);
config.addLogger(loggerConfig.getName(), loggerConfig);
{code}
Except {{LogManager}} and {{{}Level{}}}, all the classes above are from
{{{}org.apache.logging.log4j.core{}}}.
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] LF-Lin commented on pull request #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
LF-Lin commented on pull request #800: URL: https://github.com/apache/logging-log4j2/pull/800#issuecomment-1069149812 > Hi @LF-Lin Thank you for your PR. In order to make this use-case more obvious in the test, I choose a different implementation; please pull the branch and try your local build. Let us know what your results are. TY! Nice implementation. Test passes! -- 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-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507617#comment-17507617 ] Pooja Pandey commented on LOG4J2-3437: -- [~pkarwasz], other than above, we have below use case scenario and trying to figure out solution. Requirement: We are trying to migrate our application from log4j1.x to log4j2.x using log4j1.x bridge 2.17.2. We have many loggers and each logger is running in its own thread with its own log level threshold. The approach used here is to capture the threshold setting as a thread local variable. The value of the variable is used in an override of the getEffectiveLevel method from log4j’s Logger class. log4j uses getEffectiveLevel internally to determine the threshold for logging messages. The net effect of this approach is that a body of code can set the threshold at a higher logical level of the code and all lower level code invoked by that level will respect the lower threshold without needing be otherwise told. On exit from the high level function, it must clear the threshold setting so that other operations that reuse the thread do not encounter a spurious setting. Above requirement is not getting fulfilled with just bridge approach because it looks like that getEffectiveLevel() is not getting called internally. Please let me know if you have any idea about the solution. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507598#comment-17507598 ] Pooja Pandey edited comment on LOG4J2-3437 at 3/16/22, 1:24 PM: Thanks [~pkarwasz]. I get below runtime error with this code, java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:203) at java.util.Arrays$ArrayList.(Arrays.java:3813) at java.util.Arrays.asList(Arrays.java:3800) at org.apache.logging.log4j.core.config.LoggerConfig.getLevelAndRefs(LoggerConfig.java:951) at org.apache.logging.log4j.core.config.LoggerConfig$Builder.build(LoggerConfig.java:225) at logger.TestAppender2.addAppender(TestAppender2.java:624) at logger.TestAppender2.setUp(TestAppender2.java:592) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69) at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33) at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221) at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54) Log written to file C:\Users\Pooja.Pandey\AppData\Local\Temp\dummyOutput502622014804752235.log java.lang.NullPointerException at java.util.Objects.requireNonNull(Objects.java:203) at java.util.Arrays$ArrayList.(Arrays.java:3813) at java.util.Arrays.asList(Arrays.java:3800) at org.apache.logging.log4j.core.config.LoggerConfig.getLevelAndRefs(LoggerConfig.java:951) at org.apache.logging.log4j.core.config.LoggerConfig$Builder.build(LoggerConfig.java:225) at logger.TestAppender2.addAppender(TestAppender2.java:624) at logger.TestAppender2.setUp(TestAppender2.java:592) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507598#comment-17507598 ] Pooja Pandey commented on LOG4J2-3437: -- Thanks [~pkarwasz]. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory commented on pull request #802: Bump activemq-broker from 5.16.4 to 5.17.0
garydgregory commented on pull request #802: URL: https://github.com/apache/logging-log4j2/pull/802#issuecomment-1069119969 I wonder how this build passes because MQ is now documented to require Java 11 and the MQ POM specifies a Java 11 compiler target. -- 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-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507588#comment-17507588
]
Piotr Karwasz commented on LOG4J2-3437:
---
{{LogManager}} is the one from the Log4j 2.x API. These are the explicit
imports used in the code above
{code:java}
import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.core.Appender;
import org.apache.logging.log4j.core.Logger;
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.appender.FileAppender;
import org.apache.logging.log4j.core.config.Configuration;
import org.apache.logging.log4j.core.config.LoggerConfig;
{code}
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507554#comment-17507554 ] Pooja Pandey edited comment on LOG4J2-3437 at 3/16/22, 1:01 PM: [~pkarwasz], Thanks for your response. I see that below code doesn't compile since getContext() is not accessible. final Configuration config = ((LoggerContext) LogManager.getContext(false)).getConfiguration(); was (Author: JIRAUSER285751): [~pkarwasz], Thanks for your response. I see that below code doesn't execute since getContext() is not accessible. final Configuration config = ((LoggerContext) LogManager.getContext(false)).getConfiguration(); > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507554#comment-17507554 ] Pooja Pandey edited comment on LOG4J2-3437 at 3/16/22, 12:52 PM: - [~pkarwasz], Thanks for your response. I see that below code doesn't execute since getContext() is not accessible. final Configuration config = ((LoggerContext) LogManager.getContext(false)).getConfiguration(); was (Author: JIRAUSER285751): [~pkarwasz], Thanks for your response. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory commented on pull request #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
garydgregory commented on pull request #800: URL: https://github.com/apache/logging-log4j2/pull/800#issuecomment-1069089222 Hi @LF-Lin Thank you for your PR. In order to make this use-case more obvious in the test, I choose a different implementation; please pull the branch and try your local build. Let us know what your results are. TY! -- 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-3019) HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
[
https://issues.apache.org/jira/browse/LOG4J2-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507568#comment-17507568
]
ASF subversion and git services commented on LOG4J2-3019:
-
Commit 8f1fc1bf46cf054fd2dcf99faf1c731dc3e9e82d in logging-log4j2's branch
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8f1fc1b ]
[LOG4J2-3019] HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test
fails on windows
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
> -
>
> Key: LOG4J2-3019
> URL: https://issues.apache.org/jira/browse/LOG4J2-3019
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: OS: Windows 10 Enterprise
> Version: 20H2
> OS Build: 19042.746
> Experience: Windows Feature Experience Pack 120.2212.551.0
> java version "1.8.0_192"
> Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
>Reporter: Luc Kleeven
>Assignee: Volkan Yazici
>Priority: Minor
>
> When running a './mvnw verify' on the 'release-2.x' branche, last commit id
> '9788f33fc62b3b4012489a603772433d3440e6b0'. The following test fails:
> {code:java}
> [ERROR]
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
> Incorrect date=02 Nov 2012 21:34:02,123, format=DATE,
> timezone=GMT+8 ==> expected: <02 nov 2012 21:34:02,123> but was:
> <02 Nov 2012 21:34:02,123> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507554#comment-17507554 ] Pooja Pandey commented on LOG4J2-3437: -- [~pkarwasz], Thanks for your response. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507544#comment-17507544
]
Piotr Karwasz commented on LOG4J2-3437:
---
[~PoojaTheCoder]: that API is not implemented (it is almost a no-op).
However you can do the same thing using native Log4j 2.x Core APIs:
{code:java}
final Logger logger = (Logger)
LogManager.getLogger("org.apache.logging.example");
final Configuration config = ((LoggerContext)
LogManager.getContext(false)).getConfiguration();
// FileAppender
final Appender appender = FileAppender.newBuilder()
.setConfiguration(config)
.setName("unique_name")
.withFileName("filename")
.build();
appender.start();
// 'threshold' can be translated in many ways, e.g. an AppenderRef level:
final LoggerConfig loggerConfig = LoggerConfig.newBuilder()
.withConfig(config)
.withLoggerName(logger.getName())
.build();
loggerConfig.addAppender(appender, /*AppenderRef level*/ Level.DEBUG,
/*AppenderRef filter*/null);
config.addLogger(loggerConfig.getName(), loggerConfig);
{code}
Except {{LogManager}} and {{Level}}, all the classes above are from
{{org.apache.logging.log4j.core}}.
> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
> I understand that currently log4j 1.x bridge 2.17.2 doesn't support
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
> # *They must not programmatically configure Log4j.*
>
> In our application, we have a requirement where we need to add many
> FileAppender programmatically with various log threshold values.
>
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>
--
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=17507518#comment-17507518
]
Ragini Gawande edited comment on LOG4J2-3419 at 3/16/22, 11:25 AM:
---
[~pkarwasz]
I tried with the new snapshot version log4j-1.2-api-2.17.3-snapshot.jar but I
getting following results
2022-03-16 16:45:05,836 Main[OFFid] :main: example.com.Test OFF - Ragini
Level.OFF log
2022-03-16 16:45:05,839 Main[FATALid] :main: example.com.Test FATAL - Ragini
Level.FATAL log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.ERROR log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.WARNING log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.SEVERE log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.UM_INFO log
2022-03-16 16:45:05,841 Main[INFOid] :main: example.com.Test INFO - Ragini
Level.INFO log
2022-03-16 16:45:05,842 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.CONFIG log
2022-03-16 16:45:05,843 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.FINE log
Here for all the custom levels its printing ERROR instead of printing actual
custom level and also the IDs are not printed.
was (Author: JIRAUSER285931):
[~pkarwasz]
I tried with the new snapshot version log4j-1.2-api-2.17.3-snapshot.jar but I
getting following results
2022-03-16 16:45:05,836 Main[OFFid] :main: example.com.Test OFF - Ragini
Level.OFF log
2022-03-16 16:45:05,839 Main[FATALid] :main: example.com.Test FATAL - Ragini
Level.FATAL log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.ERROR log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.WARNING log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.SEVERE log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.UM_INFO log
2022-03-16 16:45:05,841 Main[INFOid] :main: example.com.Test INFO - Ragini
Level.INFO log
2022-03-16 16:45:05,842 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.CONFIG log
2022-03-16 16:45:05,843 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.FINE log
Here for all the custom levels its printing ERROR instead of printing actual
custom 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
> 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=17507518#comment-17507518
]
Ragini Gawande commented on LOG4J2-3419:
[~pkarwasz]
I tried with the new snapshot version log4j-1.2-api-2.17.3-snapshot.jar but I
getting following results
2022-03-16 16:45:05,836 Main[OFFid] :main: example.com.Test OFF - Ragini
Level.OFF log
2022-03-16 16:45:05,839 Main[FATALid] :main: example.com.Test FATAL - Ragini
Level.FATAL log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.ERROR log
2022-03-16 16:45:05,840 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.WARNING log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.SEVERE log
2022-03-16 16:45:05,841 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.UM_INFO log
2022-03-16 16:45:05,841 Main[INFOid] :main: example.com.Test INFO - Ragini
Level.INFO log
2022-03-16 16:45:05,842 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.CONFIG log
2022-03-16 16:45:05,843 Main[ERRORid] :main: example.com.Test ERROR - Ragini
Level.FINE log
Here for all the custom levels its printing ERROR instead of printing actual
custom 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
> 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-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507510#comment-17507510 ] Pooja Pandey commented on LOG4J2-3437: -- Hi [~ggregory], We are trying to use Logger.addAppender(Appender newAppender) method dynamically. > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
[ https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507506#comment-17507506 ] Gary D. Gregory commented on LOG4J2-3437: - Hi [~PoojaTheCoder] Would you provide an example program to show which APIs you use? > Log4j 1.x bridge Request to support programmatically configuring Log4j. > --- > > Key: LOG4J2-3437 > URL: https://issues.apache.org/jira/browse/LOG4J2-3437 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > > As per log4j migration documentation > ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] > I understand that currently log4j 1.x bridge 2.17.2 doesn't support > programmatically configuring log4j appenders. > * Limitations of the Log4j 1.x bridge* > # *They must not programmatically configure Log4j.* > > In our application, we have a requirement where we need to add many > FileAppender programmatically with various log threshold values. > > Hoping to get this feature supported in future versions for log4j1.x bridge. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3434) Property is not populating "value"
[
https://issues.apache.org/jira/browse/LOG4J2-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507442#comment-17507442
]
Piotr Karwasz commented on LOG4J2-3434:
---
Hello [~ck945fi],
The solution to [LOG4J2-3424|https://issues.apache.org/jira/browse/LOG4J2-3424]
probably fixed also this issue. Can you check with the latest 2.17.3-SNAPSHOT?
> Property is not populating "value"
> --
>
> Key: LOG4J2-3434
> URL: https://issues.apache.org/jira/browse/LOG4J2-3434
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Kai
>Priority: Major
>
> When specifying Property for customized appender like:
> {code:java}
> {code}
> It used to populating Property.value with "value1".
> But after upgrading to 2.17.2 with introduce of "rawValue", only "rawValue"
> is populated but "value" stays null.
> Note: current solution for us is to roll back to 2.17.1, which is not ideal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3434) Property is not populating "value"
[
https://issues.apache.org/jira/browse/LOG4J2-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai updated LOG4J2-3434:
Description:
When specifying Property for customized appender like:
{code:java}
{code}
It used to populating Property.value with "value1".
But after upgrading to 2.17.2 with introduce of "rawValue", only "rawValue" is
populated but "value" stays null.
Note: current solution for us is to roll back to 2.17.1, which is not ideal.
was:
When specifying Property for customized appender like:
{code:java}
{code}
It used to populating Property.value with "value1".
But after upgrading to 2.17.2 with introduce of "rawValue", only "rawValue" is
populated but "value" stays null.
> Property is not populating "value"
> --
>
> Key: LOG4J2-3434
> URL: https://issues.apache.org/jira/browse/LOG4J2-3434
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Kai
>Priority: Major
>
> When specifying Property for customized appender like:
> {code:java}
> {code}
> It used to populating Property.value with "value1".
> But after upgrading to 2.17.2 with introduce of "rawValue", only "rawValue"
> is populated but "value" stays null.
> Note: current solution for us is to roll back to 2.17.1, which is not ideal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[
https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507396#comment-17507396
]
Piotr Karwasz commented on LOG4J2-3436:
---
Hi [~ragini],
Thanks for the additional info. Log4j uses a simple wrapper around
[InetAddress#getLocalHost()|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/InetAddress.html#getLocalHost()]
to retrieve your hostname. Basically this is equivalent to a call to {{uname
-n}} with a twist: the name must be resolvable. You can check it with:
{noformat}
getent hosts rag101ga
{noformat}
My guess is that resolution of {{rag101ga}} fails on your system and Log4j
falls back to a reverse lookup of all your IP addresses (except the loopback
addresses). One of them must give {{localhost.localdomain}} as an answer.
You can work around this problem by adding to {{/etc/hosts}} an entry like
{noformat}
127.0.1.1 rag101ga.example.com rag101ga
{noformat}
PS: I think the fallback mechanism is incomplete. While trying to reproduce
your symptoms I got a literal IP address as hostname.
> Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
> --
>
> Key: LOG4J2-3436
> URL: https://issues.apache.org/jira/browse/LOG4J2-3436
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Log4j 1.2 bridge
> Environment: Using log4j 2 bridge API: snapshot version of 2.17.3
> log4j-1.2-api-2.17.3.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> We are trying to use syslogAppender for our logging but in the logs its
> prints localhost.localdomain instead of actual hostname
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can
> print FINE
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can
> print Info
>
> Here we are using snapshot version of log4j 2.17.3
> This issue was not seen when using log4j 2.17.1
>
> Additional info:
> JDK 1.8
> -Dlog4j1.compatibility=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
