[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489469#comment-17489469
]
Gary D. Gregory commented on LOG4J2-3317:
-
Sounds like we better have a unit test that covers that use case, then you
won't have to worry about it from commit to commit, release to release.
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[
https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488550#comment-17488550
]
Gary D. Gregory edited comment on LOG4J2-3391 at 2/8/22, 1:52 PM:
--
[~ugurlu]
Please test git master or a 2.17.2-SNAPSHOT build.
Example configuration:
{code:xml}
{code}
The above works as tested with the {{log4j-mongodb3}} and {{log4j-mongodb4}}
modules.
was (Author: garydgregory):
[~ugurlu]
Please test git master or a 2.17.2-SNAPSHOT build.
Example configuration:
{code:xml}
{code}
The above works and is tested with the {{log4j-mongodb3}} and
{{log4j-mongodb4}} modules.
> Add optional additional fields to NoSQLAppender
> ---
>
> Key: LOG4J2-3391
> URL: https://issues.apache.org/jira/browse/LOG4J2-3391
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Additional fields cannot be added to NoSQLAppender logs.
> I wasn't able to way a find of attaching fields application server hostname
> or a simple tag like application server name.
> Only way of adding custom information seems to be ThreadContext
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[
https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488550#comment-17488550
]
Gary D. Gregory edited comment on LOG4J2-3391 at 2/8/22, 2:16 AM:
--
[~ugurlu]
Please test git master or a 2.17.2-SNAPSHOT build.
Example configuration:
{code:xml}
{code}
The above works and is tested with the {{log4j-mongodb3}} and
{{log4j-mongodb4}} modules.
was (Author: garydgregory):
[~ugurlu]
Please test git master or a 2.17.2-SNAPSHOT build.
Example configuration:
{code:xml}
{code}
> Add optional additional fields to NoSQLAppender
> ---
>
> Key: LOG4J2-3391
> URL: https://issues.apache.org/jira/browse/LOG4J2-3391
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Additional fields cannot be added to NoSQLAppender logs.
> I wasn't able to way a find of attaching fields application server hostname
> or a simple tag like application server name.
> Only way of adding custom information seems to be ThreadContext
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[
https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488550#comment-17488550
]
Gary D. Gregory commented on LOG4J2-3391:
-
[~ugurlu]
Please test git master or a 2.17.2-SNAPSHOT build.
Example configuration:
{code:xml}
{code}
> Add optional additional fields to NoSQLAppender
> ---
>
> Key: LOG4J2-3391
> URL: https://issues.apache.org/jira/browse/LOG4J2-3391
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
>
> Additional fields cannot be added to NoSQLAppender logs.
> I wasn't able to way a find of attaching fields application server hostname
> or a simple tag like application server name.
> Only way of adding custom information seems to be ThreadContext
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3391. - Fix Version/s: 2.17.2 Resolution: Fixed > Add optional additional fields to NoSQLAppender > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.2 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3396) ERROR Recursive call to appender mongodb with spring boot root logger
[
https://issues.apache.org/jira/browse/LOG4J2-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488522#comment-17488522
]
Gary D. Gregory commented on LOG4J2-3396:
-
Would you provide a PR on GitHub with a test that demonstrates this issue? That
would be the simplest for me to debug.
> ERROR Recursive call to appender mongodb with spring boot root logger
> -
>
> Key: LOG4J2-3396
> URL: https://issues.apache.org/jira/browse/LOG4J2-3396
> Project: Log4j 2
> Issue Type: Question
> Components: MongoDB
>Affects Versions: 2.17.1
>Reporter: Omer U
>Priority: Major
>
> If mongodb4 logger is used as root logger in basic spring boot rest
> application, it causes some sort of recursion error. And stalls startup.
> below causes recursive call error
> {code:xml}
>
>
>
>
> {code}
> while following does not produce error
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
>
> {noformat}
> 2022-02-07 23:35:43,487 cluster-ClusterId{value='620182632ff6a504abdb6699',
> description='null'}-localhost:27017 ERROR Recursive call to appender mongodb
> 23:36:13.481 [st:27017] INFO o.m.d.cluster - Cluster description not yet
> available. Waiting for 3 ms before timing out
> 2022-02-07 23:36:13,480
> cluster-rtt-ClusterId{value='620182632ff6a504abdb6697',
> description='null'}-localhost:27017 ERROR Unable to write to database
> [noSqlManager{ description=mongodb, bufferSize=0, provider=MongoDb4Provider
> [connectionString=mongodb://localhost:27017/tombolog.mongo4test,
> collectionSize=1073741824, isCapped=true,
> mongoClient=com.mongodb.client.internal.MongoClientImpl@2f67a4d3,
> mongoDatabase=com.mongodb.client.internal.MongoDatabaseImpl@5e3f861] }] for
> appender [mongodb].
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Failed to
> write log event to MongoDB due to error: Timed out after 3 ms while
> waiting to connect. Client view of cluster state is {type=UNKNOWN,
> servers=[{address=localhost:27017, type=UNKNOWN, state=CONNECTING}]
> {noformat}
> full log4j2.xml file
> {code:xml}
>
>
>
>
>
>
>
>connection="${env:MONGO_LOG_URI:-mongodb://localhost:27017/log.mongo4test}" />
>
>
>
>
>
>
>
>
>
>
>
> {code}
> build.gradle
> {code:groovy}
> plugins {
> id 'org.springframework.boot' version '2.6.3'
> id 'io.spring.dependency-management' version '1.0.11.RELEASE'
> id 'java'
> }
> group = 'com.example'
> version = '0.0.1-SNAPSHOT'
> sourceCompatibility = '11'
> ext ['log4j2.version'] = '2.17.2-SNAPSHOT'
> repositories {
> mavenCentral()
> maven {
> url "http://repository.apache.org/content/repositories/snapshots/";
> }
> }
> dependencies {
> implementation group: 'org.apache.logging.log4j', name:
> 'log4j-mongodb4', version: '2.17.2-SNAPSHOT'
> implementation 'org.springframework.boot:spring-boot-starter-web'
> implementation 'org.springframework.boot:spring-boot-starter-log4j2'
> testImplementation 'org.springframework.boot:spring-boot-starter-test'
> }
> configurations {
> all {
> exclude group: 'org.springframework.boot', module:
> 'spring-boot-starter-logging'
> exclude group: 'org.springframework.boot', module:
> 'logback-classic'
> }
> }
> tasks.named('test') {
> useJUnitPlatform()
> }
> {code}
> is this normal behavior? I have tried to reproduce this without spring boot
> without any success.
> Any ideas?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3391: Summary: Add optional additional fields to NoSQLAppender (was: NoSQLAppender additional fields) > Add optional additional fields to NoSQLAppender > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3391) Add optional additional fields to NoSQLAppender
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3391: Fix Version/s: (was: 2.16.0) > Add optional additional fields to NoSQLAppender > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3391) NoSQLAppender additional fields
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488268#comment-17488268 ] Gary D. Gregory edited comment on LOG4J2-3391 at 2/7/22, 5:09 PM: -- I should be able to put some time into this soon-ish. I prototyped over the weekend and there are some internals I need to clean up. was (Author: garydgregory): I should be able to put some time into this soon-ish. > NoSQLAppender additional fields > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3391) NoSQLAppender additional fields
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488268#comment-17488268 ] Gary D. Gregory edited comment on LOG4J2-3391 at 2/7/22, 5:09 PM: -- I should be able to put some time into this soon-ish. I prototyped successfully over the weekend and there are some internals I need to clean up. was (Author: garydgregory): I should be able to put some time into this soon-ish. I prototyped over the weekend and there are some internals I need to clean up. > NoSQLAppender additional fields > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3391) NoSQLAppender additional fields
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488268#comment-17488268 ] Gary D. Gregory commented on LOG4J2-3391: - I should be able to put some time into this soon-ish. > NoSQLAppender additional fields > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3391) NoSQLAppender additional fields
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned LOG4J2-3391: --- Assignee: Gary D. Gregory > NoSQLAppender additional fields > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (LOG4J2-3392) AppenderLoggingException logging any exception to a MongoDB Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed LOG4J2-3392.
---
> AppenderLoggingException logging any exception to a MongoDB Appender
>
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3391) NoSQLAppender additional fields
[ https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487758#comment-17487758 ] Gary D. Gregory commented on LOG4J2-3391: - Hi [~ugurlu] What does your current Log4j configuration file look like? > NoSQLAppender additional fields > --- > > Key: LOG4J2-3391 > URL: https://issues.apache.org/jira/browse/LOG4J2-3391 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Omer U >Priority: Major > Fix For: 2.16.0 > > > Additional fields cannot be added to NoSQLAppender logs. > I wasn't able to way a find of attaching fields application server hostname > or a simple tag like application server name. > Only way of adding custom information seems to be ThreadContext -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-2715) JDBCAppender commits to the DB a JTA RollbackOnly transaction and causes DB inconsistency
[
https://issues.apache.org/jira/browse/LOG4J2-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-2715.
-
Fix Version/s: 2.17.2
Resolution: Fixed
I updated the site documentation but the changes will only appear when the next
release is published.
> JDBCAppender commits to the DB a JTA RollbackOnly transaction and causes DB
> inconsistency
> -
>
> Key: LOG4J2-2715
> URL: https://issues.apache.org/jira/browse/LOG4J2-2715
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, JDBC
>Affects Versions: 2.9.1, 2.12.1
> Environment: Container Payara 5.183,
> Application: EAR using EJB 3, Hibernate 5.3.6-FINAL
> JDBC Driver: Oracle Driver ojdbc8
>Reporter: David Obber
>Priority: Critical
> Fix For: 2.17.2
>
>
> I'm using log4j2 in a Payara 5.183 server and I've enabled a JDBC Appender
> connected to a JNDI datasource.
>
>
>
>
>
> The same datasource is used by the application to talk with the db. If the
> application, that uses EJB3, marks the transaction to be rolled back
> (sessionContext.setRollbackOnly()), each statement sent to the database
> (flush(), executeUpdate()) inside the transaction must not be committed.
> What happens is that using the *jdbc appender* causes a commit that
> *{color:#de350b}writes to the database everything{color}*, *causing database
> inconsistency*.
> Using DriverManager instead of a JNDI works fine, but I don't know if I can
> set a connection pool with it.
>
> When log4j is inside a JTA transaction it should use another JDBC connection
> to log.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3390) AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge
[ https://issues.apache.org/jira/browse/LOG4J2-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487708#comment-17487708 ] Gary D. Gregory commented on LOG4J2-3390: - Hi [~dwivedv] TBH w you, I've put in as much time as I can into the 1.2 bridge for 2.17.2-SNAPSHOT and I have no motivation to put in that much work, again, for a long-dead platform like Java 6. > AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge > > > Key: LOG4J2-3390 > URL: https://issues.apache.org/jira/browse/LOG4J2-3390 > Project: Log4j 2 > Issue Type: Improvement > Components: Log4j 1.2 bridge >Affects Versions: 2.3.2 >Reporter: Vivek >Priority: Critical > > Currently log4j1 is being used in our application with Java1.6 but due to > vulnerabilities and EOL we are now trying to implement Log4j1.2 bridge in our > application. We have use Log4j2.3.2 api with Log4j1.2 bridge(For Java6) but > while running the application getting below ClassNotFoundException exception: > --- > at com.rbsfm.wssservices.argon.MessageReader.run(MessageReader.java:150) > Caused by: *java.lang.ClassNotFoundException: > org.apache.log4j.AppenderSkeleton* > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 17 more > 2022-02-03 15:25:09,564 DEBUG Stopping LoggerContext[name=3526198, > org.apache.logging.log4j.core.LoggerContext@162dbb6] > --- > Its looking like ApenderSkeleton class is missing from Log4j-1.2-api-2.3.2 > bridge jar. Could you please suggest if there is any other bridge which can > be used and compatible with java6 or we can enhance 2.3.2 bridge API. > Jars used in application : > log4j-api-2.3.2.jar > log4j-core-2.3.2.jar > log4j-1.2-api-2.3.2.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3391) NoSQLAppender additional fields
[
https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487545#comment-17487545
]
Gary D. Gregory commented on LOG4J2-3391:
-
Hello [~ugurlu]
Where do the values for such fields originate?
Are you talking about something like one can do with the JSON layout like:
{code:xml}
{code}
?
> NoSQLAppender additional fields
> ---
>
> Key: LOG4J2-3391
> URL: https://issues.apache.org/jira/browse/LOG4J2-3391
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Omer U
>Priority: Major
> Fix For: 2.16.0
>
>
> Additional fields cannot be added to NoSQLAppender logs.
> I wasn't able to way a find of attaching fields application server hostname
> or a simple tag like application server name.
> Only way of adding custom information seems to be ThreadContext
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3392) AppenderLoggingException logging any exception to a MongoDB Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3392.
-
Fix Version/s: 2.17.2
Resolution: Fixed
[~ugurlu]
Thank you for your report.
Please test {{2.17.2-SNAPSHOT}} from a local build of the git branch
{{release-2.x}} or by pointing Maven to
https://repository.apache.org/content/repositories/snapshots/
> AppenderLoggingException logging any exception to a MongoDB Appender
>
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3392) AppenderLoggingException logging any exception to a MongoDB Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3392:
Summary: AppenderLoggingException logging any exception to a MongoDB
Appender (was: Exception logging an exception with to MongoDB Appender)
> AppenderLoggingException logging any exception to a MongoDB Appender
>
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3392) Exception logging an exception with to MongoDB Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3392:
Summary: Exception logging an exception with to MongoDB Appender (was:
NoSQLAppender mongodb out of box exception support)
> Exception logging an exception with to MongoDB Appender
> ---
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3392) NoSQLAppender mongodb out of box exception support
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3392:
Summary: NoSQLAppender mongodb out of box exception support (was:
NoSQLAppender mongodb4 out of box exception support)
> NoSQLAppender mongodb out of box exception support
> --
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3394) The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
[
https://issues.apache.org/jira/browse/LOG4J2-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487514#comment-17487514
]
Gary D. Gregory commented on LOG4J2-3394:
-
This looks wrong
rootLogger = ${sys:hbase.root.logger:-INFO,console}
It should be:
rootLogger = ${sys:hbase.root.logger:-INFO},console
> The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
> ---
>
> Key: LOG4J2-3394
> URL: https://issues.apache.org/jira/browse/LOG4J2-3394
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Reporter: Duo Zhang
>Priority: Major
> Attachments: log4j2.err, log4j2.properties
>
>
> Tried the new feature introduced in LOG4J2-3341 in hbase.
> https://github.com/apache/hbase/pull/4096
> I built a tarball and try to start a standalone hbase instance locally, but
> log4j2 failed to load the system properties of rootLogger.
> Will upload the config and error output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3392) NoSQLAppender mongodb4 out of box exception support
[
https://issues.apache.org/jira/browse/LOG4J2-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3392:
---
Assignee: Gary D. Gregory
> NoSQLAppender mongodb4 out of box exception support
> ---
>
> Key: LOG4J2-3392
> URL: https://issues.apache.org/jira/browse/LOG4J2-3392
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.16.0
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
>
> Logging an exception with
> LOG.warn("test log", new RuntimeException("test ex"));
>
> does not work and throws the following exception:
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Unable to
> write to database in appender: Can't find a codec for class
> org.apache.logging.log4j.mongodb4.MongoDb4DocumentObject.
>
> There's a blog post [1] providing a workaround which is rewrite of
> MongoDb4Provider which causes classpath issues.
>
>
> [1]https://blog.termian.dev/posts/log4j2-mongodb-appender/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3390) AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge
[ https://issues.apache.org/jira/browse/LOG4J2-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486519#comment-17486519 ] Gary D. Gregory commented on LOG4J2-3390: - The best bridge version of the code is in 2.17.1 and it will get better in the next release. > AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge > > > Key: LOG4J2-3390 > URL: https://issues.apache.org/jira/browse/LOG4J2-3390 > Project: Log4j 2 > Issue Type: Improvement > Components: Log4j 1.2 bridge >Affects Versions: 2.3.2 >Reporter: Vivek >Priority: Critical > > Currently log4j1 is being used in our application with Java1.6 but due to > vulnerabilities and EOL we are now trying to implement Log4j1.2 bridge in our > application. We have use Log4j2.3.2 api with Log4j1.2 bridge(For Java6) but > while running the application getting below ClassNotFoundException exception: > --- > at com.rbsfm.wssservices.argon.MessageReader.run(MessageReader.java:150) > Caused by: *java.lang.ClassNotFoundException: > org.apache.log4j.AppenderSkeleton* > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 17 more > 2022-02-03 15:25:09,564 DEBUG Stopping LoggerContext[name=3526198, > org.apache.logging.log4j.core.LoggerContext@162dbb6] > --- > Its looking like ApenderSkeleton class is missing from Log4j-1.2-api-2.3.2 > bridge jar. Could you please suggest if there is any other bridge which can > be used and compatible with java6 or we can enhance 2.3.2 bridge API. > Jars used in application : > log4j-api-2.3.2.jar > log4j-core-2.3.2.jar > log4j-1.2-api-2.3.2.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3383) JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3383:
Affects Version/s: 2.10.0
> JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
> ---
>
> Key: LOG4J2-3383
> URL: https://issues.apache.org/jira/browse/LOG4J2-3383
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.10.0, 2.17.1
> Environment: JBoss EAP 7.2.0 on linux and windows.
> Jboss is using JMS client lib: artemis-jms-client-2.6.3.redhat-00014
>Reporter: leor amikam
>Priority: Critical
>
> We upgraded log4j2 from 2.9.0 to 2.17.1. Using the JMS appender. In our
> onMessage JMS handler, we have the following:
>
> {code:java}
> ObjectMessage objMessage = (ObjectMessage) message;
> LogEvent ev = (LogEvent) objMessage.getObject();
>
> {code}
>
> The cast to the LogEvent is now throwing this exception:
> {code:java}
> javax.jms.JMSException: readObject requires a FilteredObjectInputStream or an
> ObjectInputStream that accepts an ObjectInputFilter{code}
>
> Here is the lo4j2.xml config for the appender
>
> destinationBindingName="jms/queue/AuditQueue"
> factoryBindingName="jms/RemoteConnectionFactory"
> providerURL="http-remoting://127.0.0.1:8080"
> username=""
> password=""
>
> factoryName="org.wildfly.naming.client.WildFlyInitialContextFactory" >
>
>
>
>
>
>
> None of the underlying code has changed other than the log4j2 upgrade. Any
> suggestions?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3383) JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3383.
-
Resolution: Information Provided
> JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
> ---
>
> Key: LOG4J2-3383
> URL: https://issues.apache.org/jira/browse/LOG4J2-3383
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.17.1
> Environment: JBoss EAP 7.2.0 on linux and windows.
> Jboss is using JMS client lib: artemis-jms-client-2.6.3.redhat-00014
>Reporter: leor amikam
>Priority: Critical
>
> We upgraded log4j2 from 2.9.0 to 2.17.1. Using the JMS appender. In our
> onMessage JMS handler, we have the following:
>
> {code:java}
> ObjectMessage objMessage = (ObjectMessage) message;
> LogEvent ev = (LogEvent) objMessage.getObject();
>
> {code}
>
> The cast to the LogEvent is now throwing this exception:
> {code:java}
> javax.jms.JMSException: readObject requires a FilteredObjectInputStream or an
> ObjectInputStream that accepts an ObjectInputFilter{code}
>
> Here is the lo4j2.xml config for the appender
>
> destinationBindingName="jms/queue/AuditQueue"
> factoryBindingName="jms/RemoteConnectionFactory"
> providerURL="http-remoting://127.0.0.1:8080"
> username=""
> password=""
>
> factoryName="org.wildfly.naming.client.WildFlyInitialContextFactory" >
>
>
>
>
>
>
> None of the underlying code has changed other than the log4j2 upgrade. Any
> suggestions?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3351) JDBC Appender not working for consecutive log events with OracleDB
[
https://issues.apache.org/jira/browse/LOG4J2-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485417#comment-17485417
]
Gary D. Gregory edited comment on LOG4J2-3351 at 2/1/22, 7:04 PM:
--
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
Based on:
{code:java}
insert into RSMS.SYS_LOG
(APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
(?,?,?,?,?,XYZ.nextVal,?,?)
{code}
It looks LOG_ID should be a sequence. Is it? What is your table DDL? Shouldn't
{{XYZ.nextVal}} be {{LOG_ID.nextVal}} in your configuration file?
was (Author: garydgregory):
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
Based on:
{code:java}
insert into RSMS.SYS_LOG
(APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
(?,?,?,?,?,XYZ.nextVal,?,?)
{code}
It looks LOG_ID should be a sequence. Is it? What is your table DDL?
> JDBC Appender not working for consecutive log events with OracleDB
> --
>
> Key: LOG4J2-3351
> URL: https://issues.apache.org/jira/browse/LOG4J2-3351
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, JDBC
>Affects Versions: 2.17.1
> Environment: * OS -Windows 64 bit
> * IDE - Eclipse
> * Database - Oracle 19c
> * log4j version 2.17.1
>Reporter: Rudranshu
>Priority: Major
> Fix For: 2.17.1
>
>
> I am trying to persist logs in Oracle DB in my sample application but my
> second log event is throwing an exception
> 2022-01-19 17:48:23,022 main ERROR Unable to write to database
> [JdbcManager\{name=SYS_LOG_DB, bufferSize=0, tableName=XYZ, columnConfigs=[{
> name=APPTIER, layout=%X{appTier}, literal=null, timestamp=false }, \{
> name=ACTIVITY, layout=%X{activity}, literal=null, timestamp=false }, \{
> name=LEVELS, layout=%p, literal=null, timestamp=false }, \{ name=STACKTRACE,
> layout=%X{stackTrace}, literal=null, timestamp=false }, \{ name=MESSAGE,
> layout=%m, literal=null, timestamp=false }, \{ name=LOG_ID, layout=null,
> literal=XYZ.nextVal, timestamp=false }, \{ name=USER_ID, layout=%X{userId},
> literal=null, timestamp=false }, \{ name=TIMESTAMP, layout=null,
> literal=null, timestamp=true }], columnMappings=[]}] for appender
> [SYS_LOG_DB].
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Error
> writing to JDBC Manager 'JdbcManager\{name=SYS_LOG_DB, bufferSize=0,
> tableName=XYZ, columnConfigs=[{ name=APPTIER, layout=%X{appTier},
> literal=null, timestamp=false }, \{ name=ACTIVITY, layout=%X{activity},
> literal=null, timestamp=false }, \{ name=LEVELS, layout=%p, literal=null,
> timestamp=false }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null,
> timestamp=false }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false
> }, \{ name=LOG_ID, layout=null, literal=RSMS.SYS_LOG_SEQ.nextVal,
> timestamp=false }, \{ name=USER_ID, layout=%X{userId}, literal=null,
> timestamp=false }, \{ name=TIMESTAMP, layout=null, literal=null,
> timestamp=true }], columnMappings=[]}': JDBC connection not available
> [columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> sqlStatement=insert into RSMS.SYS_LOG
> (APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
> (?,?,?,?,?,XYZ.nextVal,?,?), factoryData=FactoryData
> [connectionSource=factory\{ public static java.sql.Connection
> appender.ConnectionFactory.getDatabaseConnection() }, tableName=RSMS.SYS_LOG,
> columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=LOG_ID, layout=null, literal=XYZ.nextVal, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> columnMappings=[], immediateFail=false, retry=true,
> reconnectIntervalMillis=5000, truncateStrings=true], connection=null,
> statement=null, reconnector=Reconnector
> [latch=java.util.concurrent.CountDownLatch@b83a9be[Count = 0],
> shutdow
[jira] [Comment Edited] (LOG4J2-3351) JDBC Appender not working for consecutive log events with OracleDB
[
https://issues.apache.org/jira/browse/LOG4J2-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485417#comment-17485417
]
Gary D. Gregory edited comment on LOG4J2-3351 at 2/1/22, 7:04 PM:
--
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
Based on:
{code:java}
insert into RSMS.SYS_LOG
(APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
(?,?,?,?,?,XYZ.nextVal,?,?)
{code}
It looks like LOG_ID should be a sequence. Is it? What is your table DDL?
Shouldn't {{XYZ.nextVal}} be {{LOG_ID.nextVal}} in your configuration file?
was (Author: garydgregory):
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
Based on:
{code:java}
insert into RSMS.SYS_LOG
(APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
(?,?,?,?,?,XYZ.nextVal,?,?)
{code}
It looks LOG_ID should be a sequence. Is it? What is your table DDL? Shouldn't
{{XYZ.nextVal}} be {{LOG_ID.nextVal}} in your configuration file?
> JDBC Appender not working for consecutive log events with OracleDB
> --
>
> Key: LOG4J2-3351
> URL: https://issues.apache.org/jira/browse/LOG4J2-3351
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, JDBC
>Affects Versions: 2.17.1
> Environment: * OS -Windows 64 bit
> * IDE - Eclipse
> * Database - Oracle 19c
> * log4j version 2.17.1
>Reporter: Rudranshu
>Priority: Major
> Fix For: 2.17.1
>
>
> I am trying to persist logs in Oracle DB in my sample application but my
> second log event is throwing an exception
> 2022-01-19 17:48:23,022 main ERROR Unable to write to database
> [JdbcManager\{name=SYS_LOG_DB, bufferSize=0, tableName=XYZ, columnConfigs=[{
> name=APPTIER, layout=%X{appTier}, literal=null, timestamp=false }, \{
> name=ACTIVITY, layout=%X{activity}, literal=null, timestamp=false }, \{
> name=LEVELS, layout=%p, literal=null, timestamp=false }, \{ name=STACKTRACE,
> layout=%X{stackTrace}, literal=null, timestamp=false }, \{ name=MESSAGE,
> layout=%m, literal=null, timestamp=false }, \{ name=LOG_ID, layout=null,
> literal=XYZ.nextVal, timestamp=false }, \{ name=USER_ID, layout=%X{userId},
> literal=null, timestamp=false }, \{ name=TIMESTAMP, layout=null,
> literal=null, timestamp=true }], columnMappings=[]}] for appender
> [SYS_LOG_DB].
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Error
> writing to JDBC Manager 'JdbcManager\{name=SYS_LOG_DB, bufferSize=0,
> tableName=XYZ, columnConfigs=[{ name=APPTIER, layout=%X{appTier},
> literal=null, timestamp=false }, \{ name=ACTIVITY, layout=%X{activity},
> literal=null, timestamp=false }, \{ name=LEVELS, layout=%p, literal=null,
> timestamp=false }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null,
> timestamp=false }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false
> }, \{ name=LOG_ID, layout=null, literal=RSMS.SYS_LOG_SEQ.nextVal,
> timestamp=false }, \{ name=USER_ID, layout=%X{userId}, literal=null,
> timestamp=false }, \{ name=TIMESTAMP, layout=null, literal=null,
> timestamp=true }], columnMappings=[]}': JDBC connection not available
> [columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> sqlStatement=insert into RSMS.SYS_LOG
> (APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
> (?,?,?,?,?,XYZ.nextVal,?,?), factoryData=FactoryData
> [connectionSource=factory\{ public static java.sql.Connection
> appender.ConnectionFactory.getDatabaseConnection() }, tableName=RSMS.SYS_LOG,
> columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=LOG_ID, layout=null, literal=XYZ.nextVal, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> columnMappings=[], immediateFail=false, retry=true,
> reconnectIntervalMillis=5000, truncateStrings=true], connection=null,
> statement=null, reconnector=Reconn
[jira] [Comment Edited] (LOG4J2-3351) JDBC Appender not working for consecutive log events with OracleDB
[
https://issues.apache.org/jira/browse/LOG4J2-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485417#comment-17485417
]
Gary D. Gregory edited comment on LOG4J2-3351 at 2/1/22, 7:03 PM:
--
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
Based on:
{code:java}
insert into RSMS.SYS_LOG
(APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
(?,?,?,?,?,XYZ.nextVal,?,?)
{code}
It looks LOG_ID should be a sequence. Is it? What is your table DDL?
was (Author: garydgregory):
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
> JDBC Appender not working for consecutive log events with OracleDB
> --
>
> Key: LOG4J2-3351
> URL: https://issues.apache.org/jira/browse/LOG4J2-3351
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, JDBC
>Affects Versions: 2.17.1
> Environment: * OS -Windows 64 bit
> * IDE - Eclipse
> * Database - Oracle 19c
> * log4j version 2.17.1
>Reporter: Rudranshu
>Priority: Major
> Fix For: 2.17.1
>
>
> I am trying to persist logs in Oracle DB in my sample application but my
> second log event is throwing an exception
> 2022-01-19 17:48:23,022 main ERROR Unable to write to database
> [JdbcManager\{name=SYS_LOG_DB, bufferSize=0, tableName=XYZ, columnConfigs=[{
> name=APPTIER, layout=%X{appTier}, literal=null, timestamp=false }, \{
> name=ACTIVITY, layout=%X{activity}, literal=null, timestamp=false }, \{
> name=LEVELS, layout=%p, literal=null, timestamp=false }, \{ name=STACKTRACE,
> layout=%X{stackTrace}, literal=null, timestamp=false }, \{ name=MESSAGE,
> layout=%m, literal=null, timestamp=false }, \{ name=LOG_ID, layout=null,
> literal=XYZ.nextVal, timestamp=false }, \{ name=USER_ID, layout=%X{userId},
> literal=null, timestamp=false }, \{ name=TIMESTAMP, layout=null,
> literal=null, timestamp=true }], columnMappings=[]}] for appender
> [SYS_LOG_DB].
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Error
> writing to JDBC Manager 'JdbcManager\{name=SYS_LOG_DB, bufferSize=0,
> tableName=XYZ, columnConfigs=[{ name=APPTIER, layout=%X{appTier},
> literal=null, timestamp=false }, \{ name=ACTIVITY, layout=%X{activity},
> literal=null, timestamp=false }, \{ name=LEVELS, layout=%p, literal=null,
> timestamp=false }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null,
> timestamp=false }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false
> }, \{ name=LOG_ID, layout=null, literal=RSMS.SYS_LOG_SEQ.nextVal,
> timestamp=false }, \{ name=USER_ID, layout=%X{userId}, literal=null,
> timestamp=false }, \{ name=TIMESTAMP, layout=null, literal=null,
> timestamp=true }], columnMappings=[]}': JDBC connection not available
> [columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> sqlStatement=insert into RSMS.SYS_LOG
> (APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
> (?,?,?,?,?,XYZ.nextVal,?,?), factoryData=FactoryData
> [connectionSource=factory\{ public static java.sql.Connection
> appender.ConnectionFactory.getDatabaseConnection() }, tableName=RSMS.SYS_LOG,
> columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=LOG_ID, layout=null, literal=XYZ.nextVal, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> columnMappings=[], immediateFail=false, retry=true,
> reconnectIntervalMillis=5000, truncateStrings=true], connection=null,
> statement=null, reconnector=Reconnector
> [latch=java.util.concurrent.CountDownLatch@b83a9be[Count = 0],
> shutdown=false], isBatchSupported=true, columnMetaData=null]
> at
> org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.checkConnection(JdbcDatabaseManager.java:507)
> at
> org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.connectAndStart(JdbcDatabaseManager.java:610)
>
[jira] [Commented] (LOG4J2-3351) JDBC Appender not working for consecutive log events with OracleDB
[
https://issues.apache.org/jira/browse/LOG4J2-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485417#comment-17485417
]
Gary D. Gregory commented on LOG4J2-3351:
-
Please run your use case with DEBUG on for Log4j itself, for example:
{code:xml}
...
{code}
> JDBC Appender not working for consecutive log events with OracleDB
> --
>
> Key: LOG4J2-3351
> URL: https://issues.apache.org/jira/browse/LOG4J2-3351
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, JDBC
>Affects Versions: 2.17.1
> Environment: * OS -Windows 64 bit
> * IDE - Eclipse
> * Database - Oracle 19c
> * log4j version 2.17.1
>Reporter: Rudranshu
>Priority: Major
> Fix For: 2.17.1
>
>
> I am trying to persist logs in Oracle DB in my sample application but my
> second log event is throwing an exception
> 2022-01-19 17:48:23,022 main ERROR Unable to write to database
> [JdbcManager\{name=SYS_LOG_DB, bufferSize=0, tableName=XYZ, columnConfigs=[{
> name=APPTIER, layout=%X{appTier}, literal=null, timestamp=false }, \{
> name=ACTIVITY, layout=%X{activity}, literal=null, timestamp=false }, \{
> name=LEVELS, layout=%p, literal=null, timestamp=false }, \{ name=STACKTRACE,
> layout=%X{stackTrace}, literal=null, timestamp=false }, \{ name=MESSAGE,
> layout=%m, literal=null, timestamp=false }, \{ name=LOG_ID, layout=null,
> literal=XYZ.nextVal, timestamp=false }, \{ name=USER_ID, layout=%X{userId},
> literal=null, timestamp=false }, \{ name=TIMESTAMP, layout=null,
> literal=null, timestamp=true }], columnMappings=[]}] for appender
> [SYS_LOG_DB].
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Error
> writing to JDBC Manager 'JdbcManager\{name=SYS_LOG_DB, bufferSize=0,
> tableName=XYZ, columnConfigs=[{ name=APPTIER, layout=%X{appTier},
> literal=null, timestamp=false }, \{ name=ACTIVITY, layout=%X{activity},
> literal=null, timestamp=false }, \{ name=LEVELS, layout=%p, literal=null,
> timestamp=false }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null,
> timestamp=false }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false
> }, \{ name=LOG_ID, layout=null, literal=RSMS.SYS_LOG_SEQ.nextVal,
> timestamp=false }, \{ name=USER_ID, layout=%X{userId}, literal=null,
> timestamp=false }, \{ name=TIMESTAMP, layout=null, literal=null,
> timestamp=true }], columnMappings=[]}': JDBC connection not available
> [columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> sqlStatement=insert into RSMS.SYS_LOG
> (APPTIER,ACTIVITY,LEVELS,STACKTRACE,MESSAGE,LOG_ID,USER_ID,TIMESTAMP) values
> (?,?,?,?,?,XYZ.nextVal,?,?), factoryData=FactoryData
> [connectionSource=factory\{ public static java.sql.Connection
> appender.ConnectionFactory.getDatabaseConnection() }, tableName=RSMS.SYS_LOG,
> columnConfigs=[\{ name=APPTIER, layout=%X{appTier}, literal=null,
> timestamp=false }, \{ name=ACTIVITY, layout=%X{activity}, literal=null,
> timestamp=false }, \{ name=LEVELS, layout=%p, literal=null, timestamp=false
> }, \{ name=STACKTRACE, layout=%X{stackTrace}, literal=null, timestamp=false
> }, \{ name=MESSAGE, layout=%m, literal=null, timestamp=false }, \{
> name=LOG_ID, layout=null, literal=XYZ.nextVal, timestamp=false }, \{
> name=USER_ID, layout=%X{userId}, literal=null, timestamp=false }, \{
> name=TIMESTAMP, layout=null, literal=null, timestamp=true }],
> columnMappings=[], immediateFail=false, retry=true,
> reconnectIntervalMillis=5000, truncateStrings=true], connection=null,
> statement=null, reconnector=Reconnector
> [latch=java.util.concurrent.CountDownLatch@b83a9be[Count = 0],
> shutdown=false], isBatchSupported=true, columnMetaData=null]
> at
> org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.checkConnection(JdbcDatabaseManager.java:507)
> at
> org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.connectAndStart(JdbcDatabaseManager.java:610)
> at
> org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.writeThrough(JdbcDatabaseManager.java:888)
> at
> org.apache.logging.log4j.core.appender.db.AbstractDatabaseManager.write(AbstractDatabaseManager.java:264)
> at
> org.apache.logging.log4j.core.appender.db.AbstractDatabaseAppender.append(AbstractDatabaseAppender.java:110)
> at
> org.apache.logging.log4j.core.co
[jira] [Resolved] (LOG4J2-3352) Log4j 1.2 bridge API hard codes the Syslog Host and port to localhost:514
[
https://issues.apache.org/jira/browse/LOG4J2-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3352.
-
Resolution: Information Provided
> Log4j 1.2 bridge API hard codes the Syslog Host and port to localhost:514
> --
>
> Key: LOG4J2-3352
> URL: https://issues.apache.org/jira/browse/LOG4J2-3352
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Reporter: Tukesh
>Priority: Blocker
>
>
>
> {code:java}
> log4j.rootLogger=DEBUG,syslog
> log4j.appender.syslog=org.apache.log4j.net.SyslogAppender
> log4j.appender.syslog.Threshold=DEBUG
> log4j.appender.syslog.syslogHost=10.133.45.108
> log4j.appender.syslog.port=
> log4j.appender.syslog.protocol=TCP
> log4j.appender.syslog.header=true
> log4j.appender.syslog.Facility=LOCAL3
> log4j.appender.syslog.layout=org.apache.log4j.PatternLayout
> log4j.appender.syslog.layout.conversionPattern=Main[%pid] :%t: %c %-4p - %m%n
> {code}
>
> {code:java}
> //
> 2022-01-19 17:57:09,499 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:114)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:162)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:133)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:326)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:303)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.LoggerExample.(LoggerExample.java:11)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at
> org.apache.logging.log4j.core.net.Tcp
[jira] [Comment Edited] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484742#comment-17484742
]
Gary D. Gregory edited comment on LOG4J2-3372 at 2/1/22, 4:23 PM:
--
It seems a console appender should specify its PatternLayout charset unless the
PatternLayout defines it explicitly.
This means our building framework needs access to a parent object when building
a child, in this case, the pattern layout would need to access the console
appender, but that is not how the configuration runs at all. Needs further
investigation. Otherwise, we need to document the Console Appender to ALWAYS
configure its layout with a charset.
Another concern ([~mattsicker] [~ralphgoers]) is that it should work as
expected, no extra config in master/3.x.
was (Author: garydgregory):
It seems a console appender should specify its PatternLayout charset unless the
PatternLayout defines it explicitly.
This means our building framework needs access to a parent object when building
a child, in this case, the pattern layout would need to access the console
appender, but that is not how the configuration runs at all. Needs further
investigation. Otherwise, we need to document the Console Appender to ALWAYS
configure its layout with a charset.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484742#comment-17484742
]
Gary D. Gregory edited comment on LOG4J2-3372 at 2/1/22, 3:34 PM:
--
It seems a console appender should specify its PatternLayout charset unless the
PatternLayout defines it explicitly.
This means our building framework needs access to a parent object when building
a child, in this case, the pattern layout would need to access the console
appender, but that is not how the configuration runs at all. Needs further
investigation. Otherwise, we need to document the Console Appender to ALWAYS
configure its layout with a charset.
was (Author: garydgregory):
It seems a console appender should specify its PatternLayout charset unless the
PatternLayout defines it explicitly.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3383) JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485260#comment-17485260
]
Gary D. Gregory edited comment on LOG4J2-3383 at 2/1/22, 2:05 PM:
--
Hello [~leor.ami...@hsntech.com]
I do not see anything obvious looking at the release notes. If you are 100%
sure that the only thing you have changed is Log4j, then I would look to see in
which Log4j version this behavior first appears. Then, we can dig deeper.
was (Author: garydgregory):
Hello [~leor.ami...@hsntech.com]
I do not see anything obvious looking at the release notes. If you are 100%
sure that the only thing you have changed is Log4j, then I would look to see in
which Log4j version this behavior first appears.
> JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
> ---
>
> Key: LOG4J2-3383
> URL: https://issues.apache.org/jira/browse/LOG4J2-3383
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.17.1
> Environment: JBoss EAP 7.2.0 on linux and windows.
> Jboss is using JMS client lib: artemis-jms-client-2.6.3.redhat-00014
>Reporter: leor amikam
>Priority: Critical
>
> We upgraded log4j2 from 2.9.0 to 2.17.1. Using the JMS appender. In our
> onMessage JMS handler, we have the following:
>
> {code:java}
> ObjectMessage objMessage = (ObjectMessage) message;
> LogEvent ev = (LogEvent) objMessage.getObject();
>
> {code}
>
> The cast to the LogEvent is now throwing this exception:
> {code:java}
> javax.jms.JMSException: readObject requires a FilteredObjectInputStream or an
> ObjectInputStream that accepts an ObjectInputFilter{code}
>
> Here is the lo4j2.xml config for the appender
>
> destinationBindingName="jms/queue/AuditQueue"
> factoryBindingName="jms/RemoteConnectionFactory"
> providerURL="http-remoting://127.0.0.1:8080"
> username=""
> password=""
>
> factoryName="org.wildfly.naming.client.WildFlyInitialContextFactory" >
>
>
>
>
>
>
> None of the underlying code has changed other than the log4j2 upgrade. Any
> suggestions?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3383) JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485260#comment-17485260
]
Gary D. Gregory commented on LOG4J2-3383:
-
Hello [~leor.ami...@hsntech.com]
I do not see anything obvious looking at the release notes. If you are 100%
sure that the only thing you have changed is Log4j, then I would look to see in
which Log4j version this behavior first appears.
> JMS Log deserialization is failing on jboss eap after upgrade to 2.17.1
> ---
>
> Key: LOG4J2-3383
> URL: https://issues.apache.org/jira/browse/LOG4J2-3383
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.17.1
> Environment: JBoss EAP 7.2.0 on linux and windows.
> Jboss is using JMS client lib: artemis-jms-client-2.6.3.redhat-00014
>Reporter: leor amikam
>Priority: Critical
>
> We upgraded log4j2 from 2.9.0 to 2.17.1. Using the JMS appender. In our
> onMessage JMS handler, we have the following:
>
> {code:java}
> ObjectMessage objMessage = (ObjectMessage) message;
> LogEvent ev = (LogEvent) objMessage.getObject();
>
> {code}
>
> The cast to the LogEvent is now throwing this exception:
> {code:java}
> javax.jms.JMSException: readObject requires a FilteredObjectInputStream or an
> ObjectInputStream that accepts an ObjectInputFilter{code}
>
> Here is the lo4j2.xml config for the appender
>
> destinationBindingName="jms/queue/AuditQueue"
> factoryBindingName="jms/RemoteConnectionFactory"
> providerURL="http-remoting://127.0.0.1:8080"
> username=""
> password=""
>
> factoryName="org.wildfly.naming.client.WildFlyInitialContextFactory" >
>
>
>
>
>
>
> None of the underlying code has changed other than the log4j2 upgrade. Any
> suggestions?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484742#comment-17484742
]
Gary D. Gregory commented on LOG4J2-3372:
-
It seems a console appender should specify its PatternLayout charset unless the
PatternLayout defines it explicitly.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484740#comment-17484740
]
Gary D. Gregory commented on LOG4J2-3372:
-
Ah, right, and if you want this to work from an IDE, you'll need a default
charset because {{sun.stdout.encoding}} and {{sun.stderr.encoding}} are only
set from a OS console, at least on Windows 10:
charset="${sys:sun.stdout.encoding:-UTF-8}"
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3381) Programmatically configuring Log4j2
[ https://issues.apache.org/jira/browse/LOG4J2-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484677#comment-17484677 ] Gary D. Gregory commented on LOG4J2-3381: - Snapshots are here: [https://repository.apache.org/snapshots/] Don't mix versions. > Programmatically configuring Log4j2 > --- > > Key: LOG4J2-3381 > URL: https://issues.apache.org/jira/browse/LOG4J2-3381 > Project: Log4j 2 > Issue Type: Question >Reporter: Jitin Dominic >Priority: Major > > During upgrading log4j2 in grails 2.5.4 application, I removed all log4j > 1.2.17 dependencies and added following dependencies pertaining to v2.17.1: > * log4j-api > * log4j-core > * log4j-1.2-api > * log4j-slf4j-impl > > I'm trying to read my _log4j2.properties_ file programmatically. We are using > PropertyConfigurator.configure() to configure the logger. > > But I noticed in the > [documentation|https://logging.apache.org/log4j/2.x/manual/migration.html] > that Log4j 1.x bridge has some limitations and we can't use it for > programmatic configuration. > Is there any alternative way to configure logger programmatically without > using PropertyConfigurator? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3381) Programmatically configuring Log4j2
[ https://issues.apache.org/jira/browse/LOG4J2-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484639#comment-17484639 ] Gary D. Gregory edited comment on LOG4J2-3381 at 1/31/22, 12:26 PM: You can try 2.17.2-SNAPSHOT where I recently added support for this API. It would be good to know if the SNAPSHOT works for your use case. was (Author: garydgregory): You can try 2.17.2-SNAPSHOT where I recently added support for this API. I would be good to know if the SNAPSHOT works for your use case. > Programmatically configuring Log4j2 > --- > > Key: LOG4J2-3381 > URL: https://issues.apache.org/jira/browse/LOG4J2-3381 > Project: Log4j 2 > Issue Type: Question >Reporter: Jitin Dominic >Priority: Major > > During upgrading log4j2 in grails 2.5.4 application, I removed all log4j > 1.2.17 dependencies and added following dependencies pertaining to v2.17.1: > * log4j-api > * log4j-core > * log4j-1.2-api > * log4j-slf4j-impl > > I'm trying to read my _log4j2.properties_ file programmatically. We are using > PropertyConfigurator.configure() to configure the logger. > > But I noticed in the > [documentation|https://logging.apache.org/log4j/2.x/manual/migration.html] > that Log4j 1.x bridge has some limitations and we can't use it for > programmatic configuration. > Is there any alternative way to configure logger programmatically without > using PropertyConfigurator? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3381) Programmatically configuring Log4j2
[ https://issues.apache.org/jira/browse/LOG4J2-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484639#comment-17484639 ] Gary D. Gregory commented on LOG4J2-3381: - You can try 2.17.2-SNAPSHOT where I recently added support for this API. I would be good to know if the SNAPSHOT works for your use case. > Programmatically configuring Log4j2 > --- > > Key: LOG4J2-3381 > URL: https://issues.apache.org/jira/browse/LOG4J2-3381 > Project: Log4j 2 > Issue Type: Question >Reporter: Jitin Dominic >Priority: Major > > During upgrading log4j2 in grails 2.5.4 application, I removed all log4j > 1.2.17 dependencies and added following dependencies pertaining to v2.17.1: > * log4j-api > * log4j-core > * log4j-1.2-api > * log4j-slf4j-impl > > I'm trying to read my _log4j2.properties_ file programmatically. We are using > PropertyConfigurator.configure() to configure the logger. > > But I noticed in the > [documentation|https://logging.apache.org/log4j/2.x/manual/migration.html] > that Log4j 1.x bridge has some limitations and we can't use it for > programmatic configuration. > Is there any alternative way to configure logger programmatically without > using PropertyConfigurator? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3380) Log4j syslog appender misses writing the 1st event after syslog service is restarted
[
https://issues.apache.org/jira/browse/LOG4J2-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3380:
Affects Version/s: 2.17.1
> Log4j syslog appender misses writing the 1st event after syslog service is
> restarted
>
>
> Key: LOG4J2-3380
> URL: https://issues.apache.org/jira/browse/LOG4J2-3380
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
> Environment: CentOS 7.9 + RSyslog Service, Application deployed in
> Tomcat and running on Java 11, Log4j2 version is 2.17.1
>Reporter: Loganathan
>Priority: Major
>
> Hi Team,
> We configured our application to push certain log messages to the local
> system Syslog. We used the Syslog appender with RFC format. There is no
> problem in writing the log to the Syslog file. But when the Syslog service is
> restarted, the next message from the application is not written to the
> Syslog. But subsequent messages are getting pushed properly.
> I enabled the debug level log for Log4j but there is no trace of any
> exception/errors when this first message is missed. I checked in the
> threaddump but there is no Reconnector running.
> One more thing, after restarting of Syslog service, when the 2nd message is
> pushed the following log message is captured,
>
> {{2022-01-27 18:07:40,120 ajp-nio-0.0.0.0-8009-exec-3 DEBUG Reconnecting
> localhost/127.0.0.1:514}}
> {{2022-01-27 18:07:40,121 ajp-nio-0.0.0.0-8009-exec-3 DEBUG Creating socket
> localhost/127.0.0.1:514}}
> {{2022-01-27 18:07:40,122 ajp-nio-0.0.0.0-8009-exec-3 DEBUG Closing
> SocketOutputStream java.net.SocketOutputStream@1a769d7}}
> {{2022-01-27 18:07:40,122 ajp-nio-0.0.0.0-8009-exec-3 DEBUG Connection to
> localhost:514 reestablished:
> Socket[addr=localhost/127.0.0.1,port=514,localport=57852]}}
>
> I am not sure what files to be attached, please let me know if any additional
> details or files are required.
> Thanks, Loganathan T
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484363#comment-17484363
]
Gary D. Gregory commented on LOG4J2-3372:
-
[~ppkarwasz]
See my comment above RE console fonts.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483930#comment-17483930
]
Gary D. Gregory edited comment on LOG4J2-3372 at 1/30/22, 1:28 PM:
---
[~o.matz]
In your console, try using a TrueType font like Lucida Console instead of the
default font.
Please post your findings here.
was (Author: garydgregory):
In your console, try using a TrueType font like Lucida Console instead of the
default font.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483930#comment-17483930
]
Gary D. Gregory commented on LOG4J2-3372:
-
In your console, try using a TrueType font like Lucida Console instead of the
default font.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483928#comment-17483928
]
Gary D. Gregory commented on LOG4J2-3372:
-
It looks like this was supposed to be fixed by LOG4J2-783
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[ https://issues.apache.org/jira/browse/LOG4J2-3372 ]
Gary D. Gregory deleted comment on LOG4J2-3372:
-
was (Author: garydgregory):
It looks like the console appender builds a bad default pattern layout: It uses
UTF-8 instead of the platform encoding.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3372) ConsoleAppender on Windows does not use platform default encoding
[
https://issues.apache.org/jira/browse/LOG4J2-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483926#comment-17483926
]
Gary D. Gregory commented on LOG4J2-3372:
-
It looks like the console appender builds a bad default pattern layout: It uses
UTF-8 instead of the platform encoding.
> ConsoleAppender on Windows does not use platform default encoding
> -
>
> Key: LOG4J2-3372
> URL: https://issues.apache.org/jira/browse/LOG4J2-3372
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Oliver Matz
>Priority: Minor
> Attachments: ConsoleEncodingExample.java, LOG4J2-3372-sceenshot.png,
> log4j2.xml
>
>
> The attached example outputs a short string containing non-ascii characters
> ("Schöner Spaß") both to System.out and via log4j2 to a ConsoleAppender with
> target SYSTEM_OUT.
> When I run the example in my IDE, it outputs the string correctly both times,
> as expected
> However, if I run the example in a console on my Windows Desktop (10.0), only
> the output to System.out is correct. The non-ascii-characters get broken in
> the output of log4j2.
> I know that a workaround is to add {{charset="IBM850"}} in the
> {{{}PatternLayout{}}}, but this clearly causes problems if the application
> runs in a different environment.
> I definitely expect that log4j uses the platform default encoding, just as
> System.out does, and this seems to be other peoples' expectation, too. See
> e.g. LOG4J2-2929, stating incorrectly that "Currently PatternLayout always
> uses the default charset if none is specified explicitly."
> Another workaround is, of course, to specify a certain encoding (e.g. UTF-8)
> both for System.out and for the PatternLayout and to require the user to set
> the windows codepage (using e.g. CHCP 65001). I dislike that approach because
> it defeats the purpose of the "platform default encoding" and places a burden
> on the user
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3349) RollingFileAppenderBuilder in log4j1 bridge does not create the appender as in log4j1
[
https://issues.apache.org/jira/browse/LOG4J2-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3349.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> RollingFileAppenderBuilder in log4j1 bridge does not create the appender as
> in log4j1
> -
>
> Key: LOG4J2-3349
> URL: https://issues.apache.org/jira/browse/LOG4J2-3349
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Achim
>Priority: Major
> Fix For: 2.17.2
>
>
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-1.2-api/src/main/java/org/apache/log4j/builders/appender/RollingFileAppenderBuilder.java]
> creates the appender with a date filePattern.
> We are using a configuration like this
> {noformat}
> log4j.appender.file=org.apache.log4j.RollingFileAppender
> log4j.appender.file.layout=org.apache.log4j.PatternLayout
> log4j.appender.file.layout.ConversionPattern=%d{DEFAULT} [%t] %-5p %-33c{1}
> %x %m%n
> log4j.appender.file.File=foobar.log
> log4j.appender.file.MaxFileSize=20KB
> log4j.appender.file.MaxBackupIndex=100
> {noformat}
> With log4j 1.2.17 this created rolled files
> foobar.log.1
> foobar.log.2
> etc
> With log4j2 and the bridge we get
> foobar.log2021-12-19
> We could live with the date pattern but it should produce
> foobar.log.2021-12-19
> But since the rollover policy is still size-based what happens if the file is
> rolled twice a day?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3219) CVE-2021-44228 on log4j version 1.2.17
[ https://issues.apache.org/jira/browse/LOG4J2-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481791#comment-17481791 ] Gary D. Gregory commented on LOG4J2-3219: - Please see https://logging.apache.org/log4j/2.x/manual/migration.html > CVE-2021-44228 on log4j version 1.2.17 > -- > > Key: LOG4J2-3219 > URL: https://issues.apache.org/jira/browse/LOG4J2-3219 > Project: Log4j 2 > Issue Type: Question > Environment: log4j version 1.2.17 > >Reporter: Arun Naik >Priority: Major > > Hi, > We are exploring CVE-2021-44228. > We are using log4j version 1.2.17. > We have not configured JMS-Appender in the log4j.xml conf file. > Is our application affected by CVE-2021-44228? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3364) Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api
[ https://issues.apache.org/jira/browse/LOG4J2-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3364. - Fix Version/s: 2.17.2 Resolution: Fixed > Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api > --- > > Key: LOG4J2-3364 > URL: https://issues.apache.org/jira/browse/LOG4J2-3364 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.1 >Reporter: luke sydenham >Priority: Major > Fix For: 2.17.2 > > > Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api > > This causes a lot of difficulty in some frameworks (apache activemq for > example) where they expect the 1.2 Logger to implement the AppenderAttachable > interface -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3364) Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api
[ https://issues.apache.org/jira/browse/LOG4J2-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481080#comment-17481080 ] Gary D. Gregory commented on LOG4J2-3364: - Hello [~iouwon] Please try 2.17.2-SNAPSHOT where this has been addressed. > Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api > --- > > Key: LOG4J2-3364 > URL: https://issues.apache.org/jira/browse/LOG4J2-3364 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.1 >Reporter: luke sydenham >Priority: Major > > Category in 1.2.17 implements AppenderAttachable but does not in v2 1.2 api > > This causes a lot of difficulty in some frameworks (apache activemq for > example) where they expect the 1.2 Logger to implement the AppenderAttachable > interface -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3359) Facility and priority missing in Syslog message when Syslog log appender and pattern layout is used with log4j1-2 bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3359:
---
Assignee: Gary D. Gregory
> Facility and priority missing in Syslog message when Syslog log appender and
> pattern layout is used with log4j1-2 bridge API
> -
>
> Key: LOG4J2-3359
> URL: https://issues.apache.org/jira/browse/LOG4J2-3359
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Environment: This issue is reproducible with log4j-2.17.1 &
> log4j-2-17-2
> JDK 1.8
> -Dlog4j1.compatibility=true
> log4j.properties file :-
> log4j.rootLogger=DEBUG,SYSLOG
> log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
> log4j.appender.SYSLOG.Threshold=DEBUG
> log4j.appender.SYSLOG.SyslogHost=localhost:514
> log4j.appender.SYSLOG.protocol=UDP
> log4j.appender.SYSLOG.Facility=LOCAL1
> log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
> log4j.appender.SYSLOG.layout.ConversionPattern=${hostName} MyMain[%pid] :%t:
> %c %-4p - %m%n
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
> Attachments: LoggerExample.java, bug_fac_pri.pcapng,
> bug_fac_pri2.pcapng.pcap, log4j.properties
>
>
> FACILITY and PRIORITY is not included when log4j bridge API sends SysLog
> message. Please find the attached pcap files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480305#comment-17480305
]
Gary D. Gregory commented on LOG4J2-3328:
-
Probably maybe possibly in 2 weeks or thereabouts, no guarantees.
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3359) Facility and priority missing in Syslog message when Syslog log appender and pattern layout is used with log4j1-2 bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480064#comment-17480064
]
Gary D. Gregory commented on LOG4J2-3359:
-
Hi [~TukeshK]
I recently fixed some issues in this area, please try a 2.17.2-SNAPSHOT build.
See
[https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/]
Please report which version of Log4j you are using.
> Facility and priority missing in Syslog message when Syslog log appender and
> pattern layout is used with log4j1-2 bridge API
> -
>
> Key: LOG4J2-3359
> URL: https://issues.apache.org/jira/browse/LOG4J2-3359
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Environment: JDK 1.8
> -Dlog4j1.compatibility=true
> log4j.properties file :-
> log4j.rootLogger=DEBUG,SYSLOG
> log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
> log4j.appender.SYSLOG.Threshold=DEBUG
> log4j.appender.SYSLOG.SyslogHost=localhost:514
> log4j.appender.SYSLOG.protocol=UDP
> log4j.appender.SYSLOG.Facility=LOCAL1
> log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
> log4j.appender.SYSLOG.layout.ConversionPattern=${hostName} MyMain[%pid] :%t:
> %c %-4p - %m%n
>Reporter: Tukesh
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng
>
>
> FACILITY and PRIORITY is not included when log4j bridge API sends SysLog
> message. Please find the attached pcap files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3354) Publish an SBOM with Log4j
[ https://issues.apache.org/jira/browse/LOG4J2-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479761#comment-17479761 ] Gary D. Gregory commented on LOG4J2-3354: - What is the difference with the BOM POM we already publish? > Publish an SBOM with Log4j > -- > > Key: LOG4J2-3354 > URL: https://issues.apache.org/jira/browse/LOG4J2-3354 > Project: Log4j 2 > Issue Type: New Feature > Components: Build >Reporter: Matt Sicker >Priority: Major > > Log4j should publish a software bill of materials (SBOM) on each release to > enable end users to more easily discover the versions of both Log4j and > related dependencies are in use in their software. [Sonatype has a blog post > explaining what SBOM > is|https://blog.sonatype.com/what-is-a-software-bill-of-materials], and OWASP > has a tool called [CycloneDX|https://cyclonedx.org/] which has a [Maven > plugin|https://github.com/CycloneDX/cyclonedx-maven-plugin] which we could > potentially use for this. > Open questions: > * Do SBOM files get published to Maven Central as additional artifacts? > * Do we add SBOM files to the source and binary archives? > * Should the generated SBOM only include required dependencies? This last > bit is less obvious since we're a library, so the end user can always > override their full dependency tree when building their app. > More options for generating an SBOM: > * [https://github.com/opensbom-generator/spdx-sbom-generator] > * [https://dependencytrack.org|https://dependencytrack.org/] - integrates > with CycloneDX (all OWASP tools) > * > [https://github.com/AevaOnline/supply-chain-synthesis/blob/main/documents/list-projects.md] > - larger list of relevant supply chain security tooling > More information about what an SBOM is, related standards, etc.: > [https://www.ntia.gov/SBOM] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3348) Upgrade path from Log4j 1 to latest version of Log4j
[ https://issues.apache.org/jira/browse/LOG4J2-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3348. - Resolution: Information Provided > Upgrade path from Log4j 1 to latest version of Log4j > > > Key: LOG4J2-3348 > URL: https://issues.apache.org/jira/browse/LOG4J2-3348 > Project: Log4j 2 > Issue Type: Bug >Reporter: Fernando de la tejera >Priority: Major > > We're using Log4j 1 version 1. We noticed that the recommendation is to go to > Log4j version 2 to address security vulnerabilities found in December last > year. We're not aware of any path to upgrade from Log4j version 1 to version > 2. Are you planning to generate an upgrade path? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (LOG4J2-3348) Upgrade path from Log4j 1 to latest version of Log4j
[ https://issues.apache.org/jira/browse/LOG4J2-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed LOG4J2-3348. --- > Upgrade path from Log4j 1 to latest version of Log4j > > > Key: LOG4J2-3348 > URL: https://issues.apache.org/jira/browse/LOG4J2-3348 > Project: Log4j 2 > Issue Type: Bug >Reporter: Fernando de la tejera >Priority: Major > > We're using Log4j 1 version 1. We noticed that the recommendation is to go to > Log4j version 2 to address security vulnerabilities found in December last > year. We're not aware of any path to upgrade from Log4j version 1 to version > 2. Are you planning to generate an upgrade path? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478060#comment-17478060
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/20/22, 1:05 PM:
---
Great explanation [~rgoers] , TY.
The bottom line here IMO, is that we need better docs:
I added some internal Javadoc for the StatusLogger
{noformat}
/**
* Constructs the singleton instance for the STATUS_LOGGER constant.
*
* This is now the logger level is set:
*
*
* If the property {@value Constants#LOG4J2_DEBUG} is {@code "true"},
then use {@link Level#TRACE}, otherwise,
* Use {@link Level#ERROR}
*
*
* This is now the listener level is set:
*
*
* If the property {@value #DEFAULT_STATUS_LISTENER_LEVEL} is set, then
use it, otherwise,
* Use {@link Level#WARN}
*
*
* See:
*
* LOG4J2-1813 Provide shorter and more intuitive way to switch on
Log4j internal debug logging. If system property
* "log4j2.debug" is defined, print all status logging.
* LOG4J2-3340 StatusLogger's log Level cannot be changed as
advertised.
*
*
*
* @param name The logger name.
* @param messageFactory The message factory.
*/
{noformat}
What this means is that you need the StatusLogger level set to a level that
will allow the listeners in the StatusLogger to kick in.
was (Author: garydgregory):
Great explanation [~rgoers] , TY.
The bottom line here IMO, is that we need better docs:
I added some internal Javadoc for the StatusLogger
This is now the logger level is set:
# If the property
["log4j2.debug"|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.util%7BConstants.java%E2%98%83Constants%5ELOG4J2_DEBUG]
is {{{}"true"{}}}, then use
{{{}[Level.TRACE|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82TRACE]{}}},
otherwise,
# Use
{{[Level.ERROR|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82ERROR]}}
This is now the listener level is set:
# If the property
["log4j2.StatusLogger.level"|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger%5EDEFAULT_STATUS_LISTENER_LEVEL]
is set, then use {_}it{_}, otherwise,
# Use
{{[Level.WARN|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82WARN]}}
What this means is that you need the StatusLogger level set to a level that
will allow the listeners in the StatusLogger to kick in.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3350) Routing appender does not expand nested variables
[
https://issues.apache.org/jira/browse/LOG4J2-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478816#comment-17478816
]
Gary D. Gregory commented on LOG4J2-3350:
-
Oops, I linked the wrong issue.
> Routing appender does not expand nested variables
> -
>
> Key: LOG4J2-3350
> URL: https://issues.apache.org/jira/browse/LOG4J2-3350
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Stefano Maioli
>Priority: Minor
> Fix For: 2.17.2
>
>
> Routing appender does not expand anymore nested variables.
> Using the configuration below, Log4J version 2.14.0 create correctly the file
> {*}C:\tmp\test.log{*}, but from Log4J version 2.17.0 the property expansion
> doesn't work anymore and a wrong file *${drive}${path}${name}* is written in
> the current working directory.
>
>
> {code:java}
>
> def
> C:
> /tmp/
> test.log
> ${drive}${path}${name}
> ${filename}.%i.backup
>
>
>
>
>
> filePattern="${filepattern}">
>
> %map{data}%n
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3350) Routing appender does not expand nested variables
[
https://issues.apache.org/jira/browse/LOG4J2-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed LOG4J2-3350.
---
Fix Version/s: 2.17.2
Resolution: Fixed
[~stemaio]
Please search Jira before creating duplicate issues.
> Routing appender does not expand nested variables
> -
>
> Key: LOG4J2-3350
> URL: https://issues.apache.org/jira/browse/LOG4J2-3350
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Stefano Maioli
>Priority: Minor
> Fix For: 2.17.2
>
>
> Routing appender does not expand anymore nested variables.
> Using the configuration below, Log4J version 2.14.0 create correctly the file
> {*}C:\tmp\test.log{*}, but from Log4J version 2.17.0 the property expansion
> doesn't work anymore and a wrong file *${drive}${path}${name}* is written in
> the current working directory.
>
>
> {code:java}
>
> def
> C:
> /tmp/
> test.log
> ${drive}${path}${name}
> ${filename}.%i.backup
>
>
>
>
>
> filePattern="${filepattern}">
>
> %map{data}%n
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3347) Test failure in TypeConverterRegistryTest (master only)
[ https://issues.apache.org/jira/browse/LOG4J2-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3347: Affects Version/s: 3.0.0 > Test failure in TypeConverterRegistryTest (master only) > --- > > Key: LOG4J2-3347 > URL: https://issues.apache.org/jira/browse/LOG4J2-3347 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Gary D. Gregory >Assignee: Matt Sicker >Priority: Major > > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 > s <<< FAILURE! - in > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest > [ERROR] > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters > Time elapsed: 0.189 s <<< FAILURE! > java.lang.AssertionError: > Expected: an instance of > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 > but: > > is a > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 > at > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Maven home: C:\Java\apache-maven-3.8.4 > Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: C:\Program > Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3347) Test failure in TypeConverterRegistryTest (master only)
[ https://issues.apache.org/jira/browse/LOG4J2-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478687#comment-17478687 ] Gary D. Gregory commented on LOG4J2-3347: - [~mattsicker] If you use the ticket number in the commit message, this issue should get a comment pointing the commit; handy ;) > Test failure in TypeConverterRegistryTest (master only) > --- > > Key: LOG4J2-3347 > URL: https://issues.apache.org/jira/browse/LOG4J2-3347 > Project: Log4j 2 > Issue Type: Bug >Reporter: Gary D. Gregory >Assignee: Matt Sicker >Priority: Major > > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 > s <<< FAILURE! - in > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest > [ERROR] > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters > Time elapsed: 0.189 s <<< FAILURE! > java.lang.AssertionError: > Expected: an instance of > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 > but: > > is a > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 > at > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Maven home: C:\Java\apache-maven-3.8.4 > Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: C:\Program > Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3348) Upgrade path from Log4j 1 to latest version of Log4j
[ https://issues.apache.org/jira/browse/LOG4J2-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478215#comment-17478215 ] Gary D. Gregory commented on LOG4J2-3348: - Hello [~delatejera] Please read https://logging.apache.org/log4j/2.x/manual/migration.html > Upgrade path from Log4j 1 to latest version of Log4j > > > Key: LOG4J2-3348 > URL: https://issues.apache.org/jira/browse/LOG4J2-3348 > Project: Log4j 2 > Issue Type: Bug >Reporter: Fernando de la tejera >Priority: Major > > We're using Log4j 1 version 1. We noticed that the recommendation is to go to > Log4j version 2 to address security vulnerabilities found in December last > year. We're not aware of any path to upgrade from Log4j version 1 to version > 2. Are you planning to generate an upgrade path? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3347) Test failure in TypeConverterRegistryTest (master only)
[ https://issues.apache.org/jira/browse/LOG4J2-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3347: Description: [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 s <<< FAILURE! - in org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest [ERROR] org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters Time elapsed: 0.189 s <<< FAILURE! java.lang.AssertionError: Expected: an instance of org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 but: is a org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 at org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: C:\Java\apache-maven-3.8.4 Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" was: [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 s <<< FAILURE! - in org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest [ERROR] org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters Time elapsed: 0.189 s <<< FAILURE! java.lang.AssertionError: Expected: an instance of org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 but: is a org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 at org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) > Test failure in TypeConverterRegistryTest (master only) > --- > > Key: LOG4J2-3347 > URL: https://issues.apache.org/jira/browse/LOG4J2-3347 > Project: Log4j 2 > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 > s <<< FAILURE! - in > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest > [ERROR] > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters > Time elapsed: 0.189 s <<< FAILURE! > java.lang.AssertionError: > Expected: an instance of > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 > but: > > is a > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 > at > org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Maven home: C:\Java\apache-maven-3.8.4 > Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: C:\Program > Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3347) Test failure in TypeConverterRegistryTest (master only)
Gary D. Gregory created LOG4J2-3347: --- Summary: Test failure in TypeConverterRegistryTest (master only) Key: LOG4J2-3347 URL: https://issues.apache.org/jira/browse/LOG4J2-3347 Project: Log4j 2 Issue Type: Bug Reporter: Gary D. Gregory [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.214 s <<< FAILURE! - in org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest [ERROR] org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters Time elapsed: 0.189 s <<< FAILURE! java.lang.AssertionError: Expected: an instance of org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter1 but: is a org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest$CustomTestClass2Converter2 at org.apache.logging.log4j.plugins.convert.TypeConverterRegistryTest.testMultipleIncomparableConverters(TypeConverterRegistryTest.java:103) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478060#comment-17478060
]
Gary D. Gregory commented on LOG4J2-3340:
-
Great explanation [~rgoers] , TY.
The bottom line here IMO, is that we need better docs:
I added some internal Javadoc for the StatusLogger
This is now the logger level is set:
# If the property
["log4j2.debug"|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.util%7BConstants.java%E2%98%83Constants%5ELOG4J2_DEBUG]
is {{{}"true"{}}}, then use
{{{}[Level.TRACE|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82TRACE]{}}},
otherwise,
# Use
{{[Level.ERROR|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82ERROR]}}
This is now the listener level is set:
# If the property
["log4j2.StatusLogger.level"|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger%5EDEFAULT_STATUS_LISTENER_LEVEL]
is set, then use {_}it{_}, otherwise,
# Use
{{[Level.WARN|eclipse-javadoc:%E2%98%82=log4j-api/src%5C/main%5C/java=/optional=/true=/=/maven.pomderived=/true=/%3Corg.apache.logging.log4j.status%7BStatusLogger.java%E2%98%83StatusLogger~StatusLogger~QString;~QMessageFactory;%E2%98%82Level%E2%98%82WARN]}}
What this means is that you need the StatusLogger level set to a level that
will allow the listeners in the StatusLogger to kick in.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:47 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting (log4j2.StatusLogger.level)
override the legacy setting (log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
What does it even mean to have the StatusLogger with settings for the logger
level and listener level to be different?
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting (log4j2.StatusLogger.level)
override the legacy setting (log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
What does it even mean to have a Status logger with settings for the logger
level and listener level to be different?
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:46 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting (log4j2.StatusLogger.level)
override the legacy setting (log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
What does it even mean to have a Status logger with settings for the logger
level and listener level to be different?
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting (log4j2.StatusLogger.level)
override the legacy setting (log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:46 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting (log4j2.StatusLogger.level)
override the legacy setting (log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting override the legacy setting
(log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:45 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting override the legacy setting
(log4j.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc
update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:45 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting override the legacy setting
(log4j2.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR? I'm inclined to default both to ERROR. I'm
also thinking of having have the new setting override the legacy setting
(log4j.debug)
If we make both ERROR, the tests need no change. Either change needs a doc
update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:43 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc
update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc a
doc update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:37 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc a
doc update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:37 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc a
doc update.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
Ok to make both WARN? Or both ERROR?
If we make both ERROR, the tests need no change. Either change needs a doc a
doc update.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:29 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR (as documented on our site).
The default listener level is WARN (as documented on our site)
I'll clarify the code and Javadoc, and make sure the tests pass.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR.
The default listener level is WARN.
I'll clarify the code and Javadoc, and make sure the tests pass.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:28 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR.
The default listener level is WARN.
I'll clarify the code and Javadoc, and make sure the tests pass.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR.
The default listener level is WARN.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory edited comment on LOG4J2-3340 at 1/18/22, 1:24 PM:
---
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, so it is confusing. There are two settings with 2
different defaults:
The default logger level is ERROR.
The default listener level is WARN.
was (Author: garydgregory):
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, first we say the simple logger's level is ERROR, then we
say the default should be WARN.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work started] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3340 started by Gary D. Gregory.
---
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3340:
---
Assignee: Gary D. Gregory
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477832#comment-17477832
]
Gary D. Gregory commented on LOG4J2-3340:
-
Note:
In StatusLogger, we have:
this.logger = new SimpleLogger("StatusLogger", Level.ERROR, false, true,
showDateTime, false, dateFormat, messageFactory, PROPS, System.err);
final Level defaultLevel = Level.toLevel(DEFAULT_STATUS_LEVEL, Level.WARN);
Which does not match, first we say the simple logger's level is ERROR, then we
say the default should be WARN.
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, if multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3022) AsyncLogger with JDBC Appender PoolingDriver not concurrent
[ https://issues.apache.org/jira/browse/LOG4J2-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477816#comment-17477816 ] Gary D. Gregory commented on LOG4J2-3022: - [~stefanwendelmann] How did you deal with your issue? Are you on 2.17.1 now? > AsyncLogger with JDBC Appender PoolingDriver not concurrent > --- > > Key: LOG4J2-3022 > URL: https://issues.apache.org/jira/browse/LOG4J2-3022 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Configuration, Core, JDBC >Affects Versions: 2.14.0, 2.13.3 > Environment: OS: Win10 Pro 2004 Build 19041.572 > Java: OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.282-b08, mixed mode) > Processor: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 CPUs), ~2.0GHz > Memory: 32768MB RAM >Reporter: Stefan Wendelmann >Priority: Critical > Attachments: recording_local_docker_mssql_asynclogger_1_runs.jfr, > recording_local_h2_file_asynclogger_1_runs.jfr > > > I tested out the JDBC Logger with a PoolingDriver on several RDBMS (mysql, > mssql, postgre) over the newest JDBC driver and some older ones. > But all have a common problem, they dont act concurrent. > I tired out the AsyncLogger, Asyc Appender, Failover etc. but nothing it > takes long to log. > Then i tried out the h2:file db and its rly fast like from 40min 30 sec in > other rdbms to 20 sec in h2 ?! > Our Application creates around 600.000 Log entrys / day, and we want to > improve logging by implementing log4j2 in our bigger project, but this is a > nogo for the application. > > I created a github repo for testing things out, flight-recorded some of the > runs here: > [stefanwendelmann/Log4j_JDBC_Test > (github.com)|https://github.com/stefanwendelmann/Log4j_JDBC_Test] > I created a Stack Overflow Question here: > [sql server - Concurrency logging to sql DB - threads not running parallel - > Stack > Overflow|https://stackoverflow.com/questions/66027315/concurrency-logging-to-sql-db-threads-not-running-parallel] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3235) Exception: Invalid byte tag in constant pool: 19 for module-info.class Java 7
[
https://issues.apache.org/jira/browse/LOG4J2-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459915#comment-17459915
]
Gary D. Gregory edited comment on LOG4J2-3235 at 1/18/22, 12:24 PM:
It looks to me like there are two issues here:
* I do not think we should have put a {{module-info.class}} into a jar file
meant for Java 7.
* This might not be BCEL's fault: It just parses the class file you give it,
or a zip file you give it, or an input stream; there is no way to tell without
knowing the version of Tomcat and BCEL.
As a workaround, you can remove this class file from the jar file.
Gary
was (Author: garydgregory):
It looks to me like there are two issues here:
* I do not think we should have put a {{module-info.class}} into a jar file
meant for Java 7.
* This might not BCEL's fault. It just parses the class file you give it, or a
zip file you give it, or an input stream; there is no way to tell without
knowing the version of Tomcat and BCEL.
As a workaround, you can remove this class file from the jar file.
Gary
> Exception: Invalid byte tag in constant pool: 19 for module-info.class Java 7
> -
>
> Key: LOG4J2-3235
> URL: https://issues.apache.org/jira/browse/LOG4J2-3235
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Reporter: Saptarshi De
>Priority: Critical
> Fix For: 2.12.1
>
>
> Due to the recent vulnerability CVE-2021-44228 and CVE-2021-45046, We are
> updating to Log4j 2.12.2 on our Java 7 environment.
> Log4j 2.12.2 is supposed to be compatible with Java 7.
> We face the below exception on startup.
> Please suggest a solution for the same.
>
> {code:java}
> 15-Dec-2021 12:55:32.722 SEVERE [localhost-startStop-1]
> org.apache.catalina.startup.ContextConfig.processAnnotationsJar Unable to
> process Jar entry [META-INF/versions/9/module-info.class] from Jar
> [jar:file:/--/log4j-api-2.12.2.jar!/] for annotations
> org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag
> in constant pool: 19
> at
> org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:97)
> at
> org.apache.tomcat.util.bcel.classfile.ConstantPool.(ConstantPool.java:55)
> at
> org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:177)
> at
> org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:85)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2011)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1961)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1936)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1897)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1149)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5066)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1101)
> at
> org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1786)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3122) Logging to Log4j2 MongoDb4 Appender get ERROR on trace, debug and info level.
[ https://issues.apache.org/jira/browse/LOG4J2-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3122. - Fix Version/s: 2.17.0 Resolution: Fixed No reply from OP, see my previous comment RE 2.17.0. > Logging to Log4j2 MongoDb4 Appender get ERROR on trace, debug and info level. > - > > Key: LOG4J2-3122 > URL: https://issues.apache.org/jira/browse/LOG4J2-3122 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.14.1 >Reporter: Red Apple >Priority: Blocker > Fix For: 2.17.0 > > Attachments: log4j2-mongodb4-appender-main.zip > > > Logging to Log4j2 MongoDb4 Appender on trace, debug and info log level give > the following error > *ERROR Recursive call to appender* > but give success result and the log got written to the mongodb database when > using warn or error log level. > Possibly something recursive call happens with info log level that causing > this bug. > [Here is the repository|https://github.com/redapel/log4j2-mongodb4-appender] > that contain the very minimal code to reproduce the error. The configuration > is provided in the *log4j2.xml* file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-1792) Support property substitution when reading Log4j 1.x property config files
[
https://issues.apache.org/jira/browse/LOG4J2-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477503#comment-17477503
]
Gary D. Gregory commented on LOG4J2-1792:
-
Right, this was fixed under a different ticket for XML, and another for
property files (AFK)
> Support property substitution when reading Log4j 1.x property config files
> --
>
> Key: LOG4J2-1792
> URL: https://issues.apache.org/jira/browse/LOG4J2-1792
> Project: Log4j 2
> Issue Type: Sub-task
> Components: Configurators
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>Priority: Major
>
> I think that Log4j1ConfigurationConverter does not handle Log4j 1.x property
> substitution correctly. Log4j 1.x let you override properties with Java
> System Properties, but Log4j 2.x only do that when you specify $\{sys:key}.
> Right?
> So the converter needs to convert from $\{key} to $\{sys:key}, and also have
> some logic to handle the case of default value when present.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3205) OutputStreamManager.flushBuffer throw NoSuchMethodError ByteBuffer.clear
[ https://issues.apache.org/jira/browse/LOG4J2-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed LOG4J2-3205. --- Resolution: Not A Bug Closing as not a bug. > OutputStreamManager.flushBuffer throw NoSuchMethodError ByteBuffer.clear > > > Key: LOG4J2-3205 > URL: https://issues.apache.org/jira/browse/LOG4J2-3205 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Reporter: dingjsh >Priority: Major > Attachments: image-2021-12-10-20-52-45-490.png, > image-2021-12-10-20-53-34-503.png, image-2021-12-10-20-54-02-134.png > > > Using mvn with jdk9, the compiled sources would throw NoSuchMethodError > ByteBuffer.clear when running in a jdk1.8 env. > if change the pom.xml, using > 8 instead of the orginal > maven.compiler.source and maven.compiler.target,it would solve the problem. > > !image-2021-12-10-20-52-45-490.png! > !image-2021-12-10-20-53-34-503.png! > !image-2021-12-10-20-54-02-134.png! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3199) Log4j2 - Strange behavior with Async Logger + JDBC Appender + Oracle DB
[
https://issues.apache.org/jira/browse/LOG4J2-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476838#comment-17476838
]
Gary D. Gregory commented on LOG4J2-3199:
-
Hi [~jacob2221]
Can you try this with 2.17.1?
TY.
> Log4j2 - Strange behavior with Async Logger + JDBC Appender + Oracle DB
> ---
>
> Key: LOG4J2-3199
> URL: https://issues.apache.org/jira/browse/LOG4J2-3199
> Project: Log4j 2
> Issue Type: Question
>Affects Versions: 2.9.1
>Reporter: Jacob Thomas
>Priority: Minor
>
> Hi,
> Below is the tech stack being used -
> Log4j2 - 2.9.1
> Spring MVC - 4.2.8.RELEASE
> Oracle JDK - 1.8
> Weblogic - 12.2
> Oracle RDBMS - 19c
> We have a Spring MVC web application deployed on weblogic 12.2 connecting to
> Oracle 19c via weblogic connection pooling. The application is using Async
> logger with JDBC Appender having configuration similar to below -
> __
> __
> __
> __
> __
> __
> __
> __
> __
> __
> __
> _ additivity="false" >_
> __
> __
>
> It is observed that when log4j2 JDBC appender uses the same connection pool
> as the web application ("appdb"), then we can see multiple DB sessions
> (v$session & v$sql) executing the "INSERT INTO API_AUDIT_LOG.." sql.
> But when we create and use a new connection pool exclusively for "log4j"
> (separate from the one used by web application), there is always only one DB
> session which is executing the "INSERT INTO API_AUDIT_LOG.." sql. This is
> irrespective of the number of connections in the pool.
> As in the second scenario, there is only one connection executing the INSERT
> statement and there are 2 CLOB columns involved, usage of Oracle DB TEMP
> space used by this DB session keeps on increasing till it uses up all the
> available TEMP space. However in the first scenario where log4j2 is sharing
> connection pool with application, there always seem to be multiple DB
> sessions issuing the INSERT sql and hence the TEMP space usage is much more
> controlled.
>
> Could you please help advise why this may be happening? Based on this is it
> safe to conclude that log4j2 should not be using a separate connection pool
> of its own; rather it should always use the same pool as the main app?
> Given this behavior, can this issue of TEMP space exhaustion happen even in
> case both app and log4j2 use the same pool? For eg: Say there is a
> substantial increase in incoming requests to app but the connection pool is
> not increased accordingly. Then there could be cases where the same sessions
> are used by log4j2 more often than before to run INSERT statement because of
> increased load.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3328.
-
Fix Version/s: 2.17.2
Resolution: Fixed
Hello [~paulcooper]
I fixed this issue in branches {{release-2.x}} and {{{}master{}}}.
Please try a local build or a version {{2.17.2-SNAPSHOT}} build from
[https://repository.apache.org/content/repositories/snapshots/]
TY.
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3328:
Summary: Log4j 1.2 bridge does not support system properties in log4j.xml
(was: Log4j bridge does not support system properties in log4j.xml)
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3328) Log4j bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3328:
---
Assignee: Gary D. Gregory
> Log4j bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3323) Breaking change in AbstractManager
[
https://issues.apache.org/jira/browse/LOG4J2-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475022#comment-17475022
]
Gary D. Gregory commented on LOG4J2-3323:
-
Hi [~rschmitt]
Make sure guys are on 2.17.1 though.
> Breaking change in AbstractManager
> --
>
> Key: LOG4J2-3323
> URL: https://issues.apache.org/jira/browse/LOG4J2-3323
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Ryan Schmitt
>Priority: Major
>
> Due to LOG4J2-1540, a breaking change was made to a protected constructor in
> a public class. The fix is to add a new constructor that has the old
> signature: {{protected AbstractManager(final String name)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3330.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474546#comment-17474546
]
Gary D. Gregory commented on LOG4J2-3330:
-
[~mlemnaru]
Please try the git branch *release-2.x* or a *2.17.2-SNAPSHOT* build from
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474497#comment-17474497
]
Gary D. Gregory edited comment on LOG4J2-3330 at 1/12/22, 1:34 PM:
---
The problems applies to the following APIs in
{{org.apache.logging.log4j.core.config.Configurator}}:
* setAllLevels(String, Level)
* Configurator.setLevel(Map)
* setLevel(String, Level)
* setRootLevel(Level)
Fixing...
was (Author: garydgregory):
The problems applies to the following APIs in
{{{}org.apache.logging.log4j.core.config.Configurator{}}}:
* setAllLevels(String, Level)
* Configurator.setLevel(Map)
* setLevel(String, Level)
* setRootLevel(Level)
Fixing...
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474497#comment-17474497
]
Gary D. Gregory commented on LOG4J2-3330:
-
The problems applies to the following APIs in
{{{}org.apache.logging.log4j.core.config.Configurator{}}}:
* setAllLevels(String, Level)
* Configurator.setLevel(Map)
* setLevel(String, Level)
* setRootLevel(Level)
Fixing...
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work started] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3330 started by Gary D. Gregory.
---
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3330) Configurator.setLevel not fetching the correct LoggerContext
[
https://issues.apache.org/jira/browse/LOG4J2-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3330:
---
Assignee: Gary D. Gregory
> Configurator.setLevel not fetching the correct LoggerContext
>
>
> Key: LOG4J2-3330
> URL: https://issues.apache.org/jira/browse/LOG4J2-3330
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Mircea Lemnaru
>Assignee: Gary D. Gregory
>Priority: Major
>
> I needed to set the log level for a certain logger in the application and for
> that I tried using the following code:
> {{Configurator.setLevel(logger,level)}} but it did not seem to set the proper
> logging level.
> After looking over the source code I have noticed the following behaviour:
> Inside setLevel there is this line:
> {code:java}
> LoggerContext loggerContext = LoggerContext.getContext(false);{code}
> Which fetches the LoggerContext for the caller class.
> In turn , LoggerContext.getContext has the following content:
>
> {code:java}
> public static LoggerContext getContext(final boolean currentContext)
> { return (LoggerContext) LogManager.getContext(currentContext); }
> {code}
>
> Which delegates the context fetching to LogManager
> LogManager in turn get's the context by passing a hardcoded class name as the
> stack marker:
> {code:java}
> private static final String FQCN = LogManager.class.getName();{code}
> Because of this , the methods LoggerContext.getContext and
> LogManager.getContext behave differently in environments with multiple
> LoggerContexts and ClassLoaders
> Test:
> # Calling LoggerContext.getContext - returns LoggerContextA - corresponding
> to the classloader of LoggerContext because if we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j)
> getContext:231, LoggerContext (org.apache.logging.log4j.core) < returns
> this
> handle:24, LogLevelChangeHandler (com.ispring.log.event) <- real caller
> class{code}
> Because of the fact that the context is fetched by providing the hardcoded
> FQCN which is LogManager ... getCallerClass(FQCN) will return LoggerContext
> instead of returning LogLevelChangeHandler ( the real caller )
> 2. Calling LogManager.getContext - returns LoggerContextB - corresponding to
> the classloader of LogLevelChangeHandler which is the correct behaviour since
> LogLevelChangeHandler is the class that is actually requesting the context.
> If we look at the stack trace:
> {code:java}
> getCallerClass:151, StackLocator (org.apache.logging.log4j.util)
> getCallerClass:70, StackLocatorUtil (org.apache.logging.log4j.util)
> getCallerClass:58, StackLocatorUtil (org.apache.logging.log4j.util)
> getContext:138, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:123, ClassLoaderContextSelector
> (org.apache.logging.log4j.core.selector)
> getContext:230, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:47, Log4jContextFactory (org.apache.logging.log4j.core.impl)
> getContext:176, LogManager (org.apache.logging.log4j) <-- break point
> handle:25, LogLevelChangeHandler (com.ispring.log.event) <--- the correct
> class to be returned{code}
> Because of the behaviour mentioned above , calling Configurator.setLevel
> doesn't have de desired effect in environments with multiple LoggerContexts (
> webapp deployed in tomcat ) because it's setting the level one some
> LoggerContext which is not the one used by the application classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472697#comment-17472697
]
Gary D. Gregory edited comment on LOG4J2-3319 at 1/11/22, 12:30 PM:
Hm, this is now giving me pause. I'm not sure why the log4j-1.2-api module is a
fragment instead of its own bundle like logj-api. At first glance, it would
seem simpler to make log4j-1.2-api a bundle as well.
Do any of the other contributors know? I'll ask on the dev mailing list,
subscribe there if you have not already.
was (Author: garydgregory):
Hm, this is now giving me pause. I'm not sure why the log4j-1.2-api module is a
fragment instead of its own bundle like logj-api.
Do any of the other contributors know? I'll ask on the dev mailing list,
subscribe there if you have not already.
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, Log4j 1.2 bridge, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
> Please see _The Eclipse-ExtensibleAPI Header_ section of Eclipse's [Platform
> Plugin-In Developer
> Guide|https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html]
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472697#comment-17472697
]
Gary D. Gregory commented on LOG4J2-3319:
-
Hm, this is now giving me pause. I'm not sure why the log4j-1.2-api module is a
fragment instead of its own bundle like logj-api.
Do any of the other contributors know?
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, Log4j 1.2 bridge, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
> Please see _The Eclipse-ExtensibleAPI Header_ section of Eclipse's [Platform
> Plugin-In Developer
> Guide|https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html]
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472697#comment-17472697
]
Gary D. Gregory edited comment on LOG4J2-3319 at 1/11/22, 12:28 PM:
Hm, this is now giving me pause. I'm not sure why the log4j-1.2-api module is a
fragment instead of its own bundle like logj-api.
Do any of the other contributors know? I'll ask on the dev mailing list,
subscribe there if you have not already.
was (Author: garydgregory):
Hm, this is now giving me pause. I'm not sure why the log4j-1.2-api module is a
fragment instead of its own bundle like logj-api.
Do any of the other contributors know?
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, Log4j 1.2 bridge, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
> Please see _The Eclipse-ExtensibleAPI Header_ section of Eclipse's [Platform
> Plugin-In Developer
> Guide|https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html]
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472147#comment-17472147
]
Gary D. Gregory commented on LOG4J2-3319:
-
I just approved the buld runs on GitHub, so let's make sure the OSGi tests
pass. Note that this would go in 2.17.2.
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, Log4j 1.2 bridge, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
> Please see _The Eclipse-ExtensibleAPI Header_ section of Eclipse's [Platform
> Plugin-In Developer
> Guide|https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html]
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
