[jira] [Created] (LOG4J2-424) JDBCAppender: Add support for data types other then String
Tihomir Meščić created LOG4J2-424: - Summary: JDBCAppender: Add support for data types other then String Key: LOG4J2-424 URL: https://issues.apache.org/jira/browse/LOG4J2-424 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Environment: All Reporter: Tihomir Meščić I am using the JDBCAppender to log to a Postgresql database. I have a table (log_entries) that's used for logging purposes. One of the attributes is of type INTEGER. The attribute is something specific for our application and we are using ThreadContext (MDC) to set the value of the parameter. Currently, log4j provides no support for integer type attributes in the Column element of the JDBC appender configuration (the only types supported are string (default), timestamp - isEventTimestamp flag and Clob - isClob flag). When using the default settings in the Column element of the JDBC appender, log4j will create a prepared statement and try to set the value using the Statement.setString() method. Of course, the JDBC driver throws an exception: Caused by: org.postgresql.util.PSQLException: ERROR: column "mn_type_d" is of type integer but expression is of type character varying Hint: You will need to rewrite or cast the expression. My appender configuration: . <-- this is of type integer in the DB but LOG4J tries to insert it as a String --> -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-323) ThreadLocal-leak on tomcat shutdown when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13796730#comment-13796730
]
Francesco Chicchiriccò commented on LOG4J2-323:
---
It's not Hudson, it's me updating log4j2 version to 2.0RC1-SNAPSHOT on Syncope
trunk :-)
Anyway, I confirm the fix works: nice job!
Regards.
> ThreadLocal-leak on tomcat shutdown when using async logging
>
>
> Key: LOG4J2-323
> URL: https://issues.apache.org/jira/browse/LOG4J2-323
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.0-beta9
> Environment: Mac OS X 10.8.4, Tomcat 7.0.42, java version 1.6.0_51
>Reporter: Michael Kloster
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.0-rc1
>
>
> When shutting down Tomcat 7.0.42, catalina.out displays the following warning
> indicating a memory leak:
> {code}
> Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:55:59 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 841 ms
> Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardServer await
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardService stopInternal
> INFO: Stopping service Catalina
> Jul 28, 2013 9:56:09 AM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/asynclog] created a ThreadLocal with key of
> type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@648bfdea]) and a
> value of type [org.apache.logging.log4j.core.async.AsyncLogger.Info] (value
> [org.apache.logging.log4j.core.async.AsyncLogger$Info@4e26d560]) but failed
> to remove it when the web application was stopped. Threads are going to be
> renewed over time to try and avoid a probable memory leak.
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-bio-8009"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-bio-8080"]
> Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-bio-8009"]
> {code}
> {code:xml|title=log4j2.xml|borderStyle=solid}
>
>
>
>filePattern="logs/my-%d{COMPACT}.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> {code:title=log4j2.xml|borderStyle=solid}
> #!/bin/bash
> CATALINA_OPTS=-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
Erico Seberino da Silva Júnior created LOG4J2-440: - Summary: exception on shutdown tomcat in Mac OSX Key: LOG4J2-440 URL: https://issues.apache.org/jira/browse/LOG4J2-440 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.0-beta9 Environment: Mac OSX (Mountain or Mavericks). Reporter: Erico Seberino da Silva Júnior Priority: Minor Apache Tomcat 7.0.47 throws exceptions (class not found for org.apache.logging.log4j.core.config.NullConfiguration) but only happens when shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
[ https://issues.apache.org/jira/browse/LOG4J2-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813892#comment-13813892 ] Erico Seberino da Silva Júnior commented on LOG4J2-440: --- I'll spend tonight thanks for reply > exception on shutdown tomcat in Mac OSX > --- > > Key: LOG4J2-440 > URL: https://issues.apache.org/jira/browse/LOG4J2-440 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-beta9 > Environment: Mac OSX (Mountain or Mavericks). >Reporter: Erico Seberino da Silva Júnior >Priority: Minor > > Apache Tomcat 7.0.47 throws exceptions (class not found for > org.apache.logging.log4j.core.config.NullConfiguration) but only happens when > shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-442) Log4j2 Database insert problem in Websphere
Barış Taşkend created LOG4J2-442:
Summary: Log4j2 Database insert problem in Websphere
Key: LOG4J2-442
URL: https://issues.apache.org/jira/browse/LOG4J2-442
Project: Log4j 2
Issue Type: Bug
Components: Appenders, Configurators
Affects Versions: 2.0-beta8
Environment: Java Web Servise in Websphere server
Reporter: Barış Taşkend
Priority: Critical
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Wepshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in wepshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
How I can solve this problem?
THX.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barış Taşkend updated LOG4J2-442:
-
Environment: Java Web Service in Websphere server (was: Java Web Servise
in Websphere server)
> Log4j2 Database insert problem in Websphere
> ---
>
> Key: LOG4J2-442
> URL: https://issues.apache.org/jira/browse/LOG4J2-442
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.0-beta8
> Environment: Java Web Service in Websphere server
>Reporter: Barış Taşkend
>Priority: Critical
>
> In my local,
> I created an log4j2.xml to config like that :
> {code:title=log4j2.xml|borderStyle=solid}
>
>
>
>
>immediateFlush="false" append="true">
>
> test %m %m %ex%n
>
>
>
>url="jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I can insert logs to text file and DB by switching loggername in my java
> class which I call log function. There no problem in my local.
> In Wepshere server,
> I call a web service for logging. I am using same config file and same java
> codes which calls log function. I can insert logs to a file but I can't
> insert logs to database. I tried both driverManager url and JNDI. But nothing
> changed. In two ways, I can't insert log to DB and program doesn't throw any
> error in try-catch. So I can't find problem where is.
> Note : There is no problem at JNDI url and drivermanager url. Because I can
> perfectly use these urls in different webservice in wepshere. Also I can
> insert log to Database in my local with same codes.
> Note : There is no problem to insert logs to txt file. only DB insertion is
> problem in Websphere server. So there isn't problem at config file classpath.
> How I can solve this problem?
> THX.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
[ https://issues.apache.org/jira/browse/LOG4J2-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813892#comment-13813892 ] Erico Seberino da Silva Júnior edited comment on LOG4J2-440 at 11/8/13 1:48 AM: Here is the exception: Nov 07, 2013 11:44:22 PM org.apache.catalina.core.StandardServer await Informações: A valid shutdown command was received via the shutdown port. Stopping the Server instance. Nov 07, 2013 11:44:22 PM org.apache.coyote.AbstractProtocol pause Informações: Pausing ProtocolHandler ["http-bio-8080"] Nov 07, 2013 11:44:22 PM org.apache.catalina.core.StandardService stopInternal Informações: Stopping service Catalina Nov 07, 2013 11:44:22 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads Grave: The web application [] appears to have started a thread named [Abandoned connection cleanup thread] but has failed to stop it. This is very likely to create a memory leak. Nov 07, 2013 11:44:22 PM org.apache.catalina.core.ApplicationContext log Informações: SessionListener: contextDestroyed() Nov 07, 2013 11:44:22 PM org.apache.catalina.core.ApplicationContext log Informações: ContextListener: contextDestroyed() Nov 07, 2013 11:44:22 PM org.apache.coyote.AbstractProtocol stop Informações: Stopping ProtocolHandler ["http-bio-8080"] Nov 07, 2013 11:44:22 PM org.apache.coyote.AbstractProtocol destroy Informações: Destroying ProtocolHandler ["http-bio-8080"] Exception in thread "Thread-3" java.lang.NoClassDefFoundError: org/apache/logging/log4j/core/config/NullConfiguration at org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:210) at org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437) Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.core.config.NullConfiguration at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) ... 2 more was (Author: erico@gmail.com): I'll spend tonight thanks for reply > exception on shutdown tomcat in Mac OSX > --- > > Key: LOG4J2-440 > URL: https://issues.apache.org/jira/browse/LOG4J2-440 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-beta9 > Environment: Mac OSX (Mountain or Mavericks). >Reporter: Erico Seberino da Silva Júnior >Priority: Minor > > Apache Tomcat 7.0.47 throws exceptions (class not found for > org.apache.logging.log4j.core.config.NullConfiguration) but only happens when > shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
[ https://issues.apache.org/jira/browse/LOG4J2-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816915#comment-13816915 ] Erico Seberino da Silva Júnior commented on LOG4J2-440: --- jar files: - log4j-api-2.0-beta9.jar - log4j-core-2.0-beta9.jar log4j2.xml file: > exception on shutdown tomcat in Mac OSX > --- > > Key: LOG4J2-440 > URL: https://issues.apache.org/jira/browse/LOG4J2-440 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-beta9 > Environment: Mac OSX (Mountain or Mavericks). >Reporter: Erico Seberino da Silva Júnior >Priority: Minor > > Apache Tomcat 7.0.47 throws exceptions (class not found for > org.apache.logging.log4j.core.config.NullConfiguration) but only happens when > shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barış Taşkend updated LOG4J2-442:
-
Priority: Blocker (was: Critical)
> Log4j2 Database insert problem in Websphere
> ---
>
> Key: LOG4J2-442
> URL: https://issues.apache.org/jira/browse/LOG4J2-442
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.0-beta8
> Environment: Java Web Service in Websphere server
>Reporter: Barış Taşkend
>Priority: Blocker
>
> In my local,
> I created an log4j2.xml to config like that :
> {code:title=log4j2.xml|borderStyle=solid}
>
>
>
>
>immediateFlush="false" append="true">
>
> test %m %m %ex%n
>
>
>
>url="jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I can insert logs to text file and DB by switching loggername in my java
> class which I call log function. There no problem in my local.
> In Wepshere server,
> I call a web service for logging. I am using same config file and same java
> codes which calls log function. I can insert logs to a file but I can't
> insert logs to database. I tried both driverManager url and JNDI. But nothing
> changed. In two ways, I can't insert log to DB and program doesn't throw any
> error in try-catch. So I can't find problem where is.
> Note : There is no problem at JNDI url and drivermanager url. Because I can
> perfectly use these urls in different webservice in wepshere. Also I can
> insert log to Database in my local with same codes.
> Note : There is no problem to insert logs to txt file. only DB insertion is
> problem in Websphere server. So there isn't problem at config file classpath.
> How I can solve this problem?
> THX.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barış Taşkend updated LOG4J2-442:
-
Description:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Wepshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in wepshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How I can solve this problem?
THX.
was:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Wepshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in wepshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
How I can solve this problem?
THX.
> Log4j2 Database insert problem in Websphere
> ---
>
> Key: LOG4J2-442
> URL: https://issues.apache.org/jira/browse/LOG4J2-442
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.0-beta8
> Environment: Java Web Service in Websphere server
>Reporter: Barış Taşkend
>Priority: Blocker
>
> In my local,
> I created an log4j2.xml to config like that :
> {code:title=log4j2.xml|borderStyle=solid}
>
>
>
>
>immediateFlush="false" append="true">
>
> test %m %m %ex%n
>
>
>
>url="jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I can insert logs to text file and DB by switching loggername in my java
> class which I call log function. There no problem in my local.
> In Wepshere server,
> I call a web service for logging. I am using same config file and same java
> codes which calls log function. I can insert logs to a file but I can't
> insert logs to database. I tried both driverManager url and JNDI. But nothing
> changed. In two ways, I can't insert log to DB and program doesn't throw any
> error in try-cat
[jira] [Updated] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barış Taşkend updated LOG4J2-442:
-
Description:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Webshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in webshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How can I solve this problem?
THX.
was:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Webshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in webshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How I can solve this problem?
THX.
> Log4j2 Database insert problem in Websphere
> ---
>
> Key: LOG4J2-442
> URL: https://issues.apache.org/jira/browse/LOG4J2-442
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.0-beta8
> Environment: Java Web Service in Websphere server
>Reporter: Barış Taşkend
>Priority: Blocker
>
> In my local,
> I created an log4j2.xml to config like that :
> {code:title=log4j2.xml|borderStyle=solid}
>
>
>
>
>immediateFlush="false" append="true">
>
> test %m %m %ex%n
>
>
>
>url="jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I can insert logs to text file and DB by switching loggername in my java
> class which I call log function. There no problem in my local.
> In Webshere server,
> I call a web service for logging. I am using same config file and same java
> codes which calls log function. I can insert logs to a file but I ca
[jira] [Updated] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barış Taşkend updated LOG4J2-442:
-
Description:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Webshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in webshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How I can solve this problem?
THX.
was:
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
test %m %m %ex%n
{code}
I can insert logs to text file and DB by switching loggername in my java class
which I call log function. There no problem in my local.
In Wepshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't insert
logs to database. I tried both driverManager url and JNDI. But nothing changed.
In two ways, I can't insert log to DB and program doesn't throw any error in
try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in wepshere. Also I can insert
log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How I can solve this problem?
THX.
> Log4j2 Database insert problem in Websphere
> ---
>
> Key: LOG4J2-442
> URL: https://issues.apache.org/jira/browse/LOG4J2-442
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.0-beta8
> Environment: Java Web Service in Websphere server
>Reporter: Barış Taşkend
>Priority: Blocker
>
> In my local,
> I created an log4j2.xml to config like that :
> {code:title=log4j2.xml|borderStyle=solid}
>
>
>
>
>immediateFlush="false" append="true">
>
> test %m %m %ex%n
>
>
>
>url="jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I can insert logs to text file and DB by switching loggername in my java
> class which I call log function. There no problem in my local.
> In Webshere server,
> I call a web service for logging. I am using same config file and same java
> codes which calls log function. I can insert logs to a file but I ca
[jira] [Commented] (LOG4J2-223) IllegalStateException thrown during Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13828906#comment-13828906
]
Barış Taşkend commented on LOG4J2-223:
--
I am facing same problem in Websphere. Did you solve this problem with this way
Nick?
> IllegalStateException thrown during Tomcat shutdown
> ---
>
> Key: LOG4J2-223
> URL: https://issues.apache.org/jira/browse/LOG4J2-223
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta5
>Reporter: Ralph Goers
>Priority: Critical
> Fix For: 2.0-beta7
>
> Attachments: log4j-223.war
>
>
> {noformat}Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardServer
> await
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardService stopInternal
> INFO: Stopping service Catalina
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.loader.WebappClassLoader loadClass
> INFO: Illegal access: this web application instance has been stopped already.
> Could not load org.apache.logging.log4j.core.config.NullConfiguration. The
> eventual following stack trace is caused by an error thrown for debugging
> purposes as well as to attempt to terminate the thread which caused the
> illegal access, and has no functional impact.
> java.lang.IllegalStateException
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1351)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Exception in thread "Thread-18" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/config/NullConfiguration
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.config.NullConfiguration
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1465)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> ... 2 more{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-223) IllegalStateException thrown during Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13828911#comment-13828911
]
Barış Taşkend commented on LOG4J2-223:
--
I am using log4j beta v9. But in websphere throws same exception. how did you
solve this problem?
> IllegalStateException thrown during Tomcat shutdown
> ---
>
> Key: LOG4J2-223
> URL: https://issues.apache.org/jira/browse/LOG4J2-223
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta5
>Reporter: Ralph Goers
>Priority: Critical
> Fix For: 2.0-beta7
>
> Attachments: log4j-223.war
>
>
> {noformat}Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardServer
> await
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardService stopInternal
> INFO: Stopping service Catalina
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.loader.WebappClassLoader loadClass
> INFO: Illegal access: this web application instance has been stopped already.
> Could not load org.apache.logging.log4j.core.config.NullConfiguration. The
> eventual following stack trace is caused by an error thrown for debugging
> purposes as well as to attempt to terminate the thread which caused the
> illegal access, and has no functional impact.
> java.lang.IllegalStateException
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1351)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Exception in thread "Thread-18" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/config/NullConfiguration
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.config.NullConfiguration
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1465)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> ... 2 more{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-457) JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped
Tihomir Meščić created LOG4J2-457: - Summary: JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped Key: LOG4J2-457 URL: https://issues.apache.org/jira/browse/LOG4J2-457 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.0-beta9 Environment: JBOSS application server, PostgreSQL database Reporter: Tihomir Meščić We use log4j 2 for logging inside our J2EE app (packaged as EAR, log4j JARs are bundled inside). The app is deployed on JBOSS EAP 6.1 app server. We are using the JDBCAppender for logging to a PostgreSQL database, and the appender is configured to use a DataSource for fetching connections. The appender is configured as follows: . The problem is: after the EAR is stopped (undeployed) log4j is not releasing the JDBC connection back to the connection pool, and after we stop/start the application a couple of times, our server becomes useless because there are no more free connections in the connection pool. I've looked at the thread dump of the server and there are a lot of threads like this: org.apache.logging.log4j.core.LoggerContext$ShutdownThread @ 0xbe447138 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-477) NPE in ClassLoaderContextSelector
[
https://issues.apache.org/jira/browse/LOG4J2-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877352#comment-13877352
]
Cédric Champeau commented on LOG4J2-477:
The Groovy build is suffering this bug. Do you have any plan to release a new
beta with this included? Thanks!
> NPE in ClassLoaderContextSelector
> -
>
> Key: LOG4J2-477
> URL: https://issues.apache.org/jira/browse/LOG4J2-477
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0-beta9
>Reporter: Tal Liron
>Assignee: Remko Popma
>
> The problem is that some classes don't have class loaders: this can happen
> when working with dynamic JVM languages (Rhino, Jython, etc.)
> Here's the stack trace I got:
> {code}
> java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:182)
> at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:145)
> at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:81)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:83)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
[ https://issues.apache.org/jira/browse/LOG4J2-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917274#comment-13917274 ] Erico Seberino da Silva Júnior commented on LOG4J2-440: --- i will try again soon! Em sábado, 1 de março de 2014, Ralph Goers (JIRA) > exception on shutdown tomcat in Mac OSX > --- > > Key: LOG4J2-440 > URL: https://issues.apache.org/jira/browse/LOG4J2-440 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-beta9 > Environment: Mac OSX (Mountain or Mavericks). >Reporter: Erico Seberino da Silva Júnior >Priority: Minor > > Apache Tomcat 7.0.47 throws exceptions (class not found for > org.apache.logging.log4j.core.config.NullConfiguration) but only happens when > shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-440) exception on shutdown tomcat in Mac OSX
[ https://issues.apache.org/jira/browse/LOG4J2-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922819#comment-13922819 ] Erico Seberino da Silva Júnior commented on LOG4J2-440: --- apparently was corrected thanks ! > exception on shutdown tomcat in Mac OSX > --- > > Key: LOG4J2-440 > URL: https://issues.apache.org/jira/browse/LOG4J2-440 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-beta9 > Environment: Mac OSX (Mountain or Mavericks). >Reporter: Erico Seberino da Silva Júnior >Priority: Minor > > Apache Tomcat 7.0.47 throws exceptions (class not found for > org.apache.logging.log4j.core.config.NullConfiguration) but only happens when > shutdown tomcat process. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-590) HTMLLayout filter stacktrace
Matej Vitásek created LOG4J2-590:
Summary: HTMLLayout filter stacktrace
Key: LOG4J2-590
URL: https://issues.apache.org/jira/browse/LOG4J2-590
Project: Log4j 2
Issue Type: Wish
Reporter: Matej Vitásek
As far as I can tell, there is no way to filter stacktrace elements in the
HTMLLayout - unlike with the PatternLayout. I propose to make this possible,
ideally re-using the property that one uses in the PatternLayout:
{noformat}
org.junit,org.apache.maven,sun.reflect,java.lang.reflect
...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-590) HTMLLayout filter stacktrace
[
https://issues.apache.org/jira/browse/LOG4J2-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956635#comment-13956635
]
Matej Vitásek commented on LOG4J2-590:
--
Ralph, absolutely correct. Let me customize the way HTMLLayout presents the
information in ways that PatternLayout does.
> HTMLLayout filter stacktrace
>
>
> Key: LOG4J2-590
> URL: https://issues.apache.org/jira/browse/LOG4J2-590
> Project: Log4j 2
> Issue Type: Wish
>Reporter: Matej Vitásek
>
> As far as I can tell, there is no way to filter stacktrace elements in the
> HTMLLayout - unlike with the PatternLayout. I propose to make this possible,
> ideally re-using the property that one uses in the PatternLayout:
> {noformat}
>
>name="filters">org.junit,org.apache.maven,sun.reflect,java.lang.reflect
>
> ...
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-448) StringIndexOutOfBounds when using property substitution
[
https://issues.apache.org/jira/browse/LOG4J2-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974854#comment-13974854
]
Després Gwénaël commented on LOG4J2-448:
Hi, I have the same issue with my test. It's easily reproducible with the conf
:
org.junit,org.apache.maven,org.eclipse,sun.reflect,java.lang.reflect
In the example I use $${date:xxx} but in real, I use a personal lookup.
> StringIndexOutOfBounds when using property substitution
> -
>
> Key: LOG4J2-448
> URL: https://issues.apache.org/jira/browse/LOG4J2-448
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-beta9
> Environment: All
>Reporter: X86core
>
> @org.apache.logging.log4j.core.lookup.StrSubstitutor# substitute(LogEvent ,
> StringBuilder , int , int , List ) @ Line 816-817 @new String(chars,
> offset, length). The String should be new String(chars,
> offset, length + lengthChange) this is because of the character
> deletion that might have happened for '$".
> See trace below:
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 63
> at java.lang.String.(String.java:201)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:848)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:761)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:737)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(StrSubstitutor.java:306)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createPluginObject(BaseConfiguration.java:720)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:595)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:587)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.doConfigure(BaseConfiguration.java:244)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.start(BaseConfiguration.java:142)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:339)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:378)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
> at
> org.slf4j.helpers.Log4jLoggerFactory$PrivateManager.getContext(Log4jLoggerFactory.java:104)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:90)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:46)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-448) StringIndexOutOfBounds when using property substitution
[
https://issues.apache.org/jira/browse/LOG4J2-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974854#comment-13974854
]
Després Gwénaël edited comment on LOG4J2-448 at 4/19/14 1:25 PM:
-
Hi, I have the same issue with my test. It's easily reproducible with the conf
:
{code:title=log4j2.xml.java|borderStyle=solid}
org.junit,org.apache.maven,org.eclipse,sun.reflect,java.lang.reflect
{code}
In the example I use $${date:xxx} but in real, I use a personal lookup.
was (Author: gdespres):
Hi, I have the same issue with my test. It's easily reproducible with the conf
:
org.junit,org.apache.maven,org.eclipse,sun.reflect,java.lang.reflect
In the example I use $${date:xxx} but in real, I use a personal lookup.
> StringIndexOutOfBounds when using property substitution
> -
>
> Key: LOG4J2-448
> URL: https://issues.apache.org/jira/browse/LOG4J2-448
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-beta9
> Environment: All
>Reporter: X86core
>
> @org.apache.logging.log4j.core.lookup.StrSubstitutor# substitute(LogEvent ,
> StringBuilder , int , int , List ) @ Line 816-817 @new String(chars,
> offset, length). The String should be new String(chars,
> offset, length + lengthChange) this is because of the character
> deletion that might have happened for '$".
> See trace below:
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 63
> at java.lang.String.(String.java:201)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:848)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:761)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:737)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(StrSubstitutor.java:306)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createPluginObject(BaseConfiguration.java:720)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:595)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:587)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.doConfigure(BaseConfiguration.java:244)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.start(BaseConfiguration.java:142)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:339)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:378)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
> at
> org.slf4j.helpers.Log4jLoggerFactory$PrivateManager.getContext(Log4jLoggerFactory.java:104)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:90)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:46)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-448) StringIndexOutOfBounds when using property substitution
[
https://issues.apache.org/jira/browse/LOG4J2-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974854#comment-13974854
]
Després Gwénaël edited comment on LOG4J2-448 at 4/19/14 1:26 PM:
-
Hi, I have the same issue with my test. It's easily reproducible with the conf
:
{code:title=log4j2.xml|borderStyle=solid}
org.junit,org.apache.maven,org.eclipse,sun.reflect,java.lang.reflect
{code}
In the example I use {noformat} $${date:xxx} {noformat} but in real, I use a
personal lookup.
was (Author: gdespres):
Hi, I have the same issue with my test. It's easily reproducible with the conf
:
{code:title=log4j2.xml.java|borderStyle=solid}
org.junit,org.apache.maven,org.eclipse,sun.reflect,java.lang.reflect
{code}
In the example I use $${date:xxx} but in real, I use a personal lookup.
> StringIndexOutOfBounds when using property substitution
> -
>
> Key: LOG4J2-448
> URL: https://issues.apache.org/jira/browse/LOG4J2-448
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.0-beta9
> Environment: All
>Reporter: X86core
>
> @org.apache.logging.log4j.core.lookup.StrSubstitutor# substitute(LogEvent ,
> StringBuilder , int , int , List ) @ Line 816-817 @new String(chars,
> offset, length). The String should be new String(chars,
> offset, length + lengthChange) this is because of the character
> deletion that might have happened for '$".
> See trace below:
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: 63
> at java.lang.String.(String.java:201)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:848)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:761)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:737)
> at
> org.apache.logging.log4j.core.lookup.StrSubstitutor.replace(StrSubstitutor.java:306)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createPluginObject(BaseConfiguration.java:720)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:595)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.createConfiguration(BaseConfiguration.java:587)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.doConfigure(BaseConfiguration.java:244)
> at
> org.apache.logging.log4j.core.config.BaseConfiguration.start(BaseConfiguration.java:142)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:339)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:378)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
> at
> org.slf4j.helpers.Log4jLoggerFactory$PrivateManager.getContext(Log4jLoggerFactory.java:104)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:90)
> at
> org.slf4j.helpers.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:46)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-348) Java2 Security for OSGi Bundles
[
https://issues.apache.org/jira/browse/LOG4J2-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976555#comment-13976555
]
Łukasz Dywicki commented on LOG4J2-348:
---
You don't need any extra entries in maven-bundle-plugin configuration as long
as you will place permission file in src/main/resources/OSGI-INF.
> Java2 Security for OSGi Bundles
> ---
>
> Key: LOG4J2-348
> URL: https://issues.apache.org/jira/browse/LOG4J2-348
> Project: Log4j 2
> Issue Type: Improvement
> Components: API, Appenders, Core, JCL Bridge, log4j 1.2 emulation
>Affects Versions: 2.0
> Environment: OSGi / Apache Felix 4.x
>Reporter: Roland Weiglhofer
>Assignee: Matt Sicker
>Priority: Minor
> Labels: OSGi, Security
> Fix For: 2.0
>
>
> OSGi defines permissions for bundles. Bundles should have only those
> permissions that they need to function. This is very easy to implement. Just
> add a directory OSGI-INF in the jar and include the file permissions.perm.
> Here are some examples
> (org.osgi.framework.PackagePermission "package name" "import")
> (org.osgi.framework.PackagePermission "package name" "export")
> (org.osgi.framework.BundlePermission "groupID.artifactID of Host" "host");
> (org.osgi.framework.ServicePermission "class name" "get")
> (org.osgi.framework.ServicePermission "class name" "register")
> (org.osgi.framework.ConfigurationPermission * "configure")
> (org.osgi.framework.AdminPermission * "metadata")
> pom
> ...
>
>
>
> OSGI-INF/
> true
>
> permissions.perm
>
>
>
>
>
> org.apache.felix
> maven-bundle-plugin
> ...
>
> ...
>
> ...
>
> {maven-resources},
> OSGI-INF/=OSGI-INF/
>
> ...
>
> ...
>
> ...
>
> ...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-611) Logj 1.2 emulation is not complete
Mikael Ståldal created LOG4J2-611:
-
Summary: Logj 1.2 emulation is not complete
Key: LOG4J2-611
URL: https://issues.apache.org/jira/browse/LOG4J2-611
Project: Log4j 2
Issue Type: Bug
Components: log4j 1.2 emulation
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast to
fail since it tries to use this constructor:
{{org.apache.log4j.spi.LoggingEvent.(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
It is used here (line 117):
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978364#comment-13978364
]
Mikael Ståldal commented on LOG4J2-611:
---
Well, I would say that Hazelcast _is_ a tool that log via Log4j 1.x. But
perhaps Hazelcast is abusing the Log4j 1.x API.
However, I tried to configure Hazelcast to use SLF4J instead, and injected the
SLF4J bridge to Log4J 2. And that seems to work. So problem solved for me.
> Logj 1.2 emulation is not complete
> --
>
> Key: LOG4J2-611
> URL: https://issues.apache.org/jira/browse/LOG4J2-611
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>
> The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
> to fail since it tries to use this constructor:
> {{org.apache.log4j.spi.LoggingEvent.(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
> It is used here (line 117):
> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-611:
--
Priority: Minor (was: Major)
> Logj 1.2 emulation is not complete
> --
>
> Key: LOG4J2-611
> URL: https://issues.apache.org/jira/browse/LOG4J2-611
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
> to fail since it tries to use this constructor:
> {{org.apache.log4j.spi.LoggingEvent.(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
> It is used here (line 117):
> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1397#comment-1397
]
Mikael Ståldal commented on LOG4J2-611:
---
I don't like to be tied to SLF4J though, so I'm trying to get Hazelcast to
implement proper support for Log4j 2:
https://github.com/hazelcast/hazelcast/issues/2345
> Logj 1.2 emulation is not complete
> --
>
> Key: LOG4J2-611
> URL: https://issues.apache.org/jira/browse/LOG4J2-611
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
> to fail since it tries to use this constructor:
> {{org.apache.log4j.spi.LoggingEvent.(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
> It is used here (line 117):
> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980793#comment-13980793
]
Mikael Ståldal commented on LOG4J2-611:
---
Yes, this issue can be closed now.
I have sent my Hazelcast factory to Ralph for review, and I will then try to
contribute it to the Hazelcast project.
However, I think it is important that Log4j 2 does not depend on SLF4J, and
that we strive to get other projects use Log4j 2 directly. SLF4J is problematic
when you try to use it multiple times in the same JVM, such as using it to get
Hazelcast to log via Log4j 2 in a web app, AND also use SLF4J to get Jetty to
log via Log4j 2. It seems like either of them works separately, but not both at
the same time.
I like Log4j 2 since you get an SLF4J like API without all this mess that SLF4J
creates. IMHO, having a generic log wrapper is a broken concept, and SLF4J is
not better than Commons-Logging, it just breaks in a different way.
> Logj 1.2 emulation is not complete
> --
>
> Key: LOG4J2-611
> URL: https://issues.apache.org/jira/browse/LOG4J2-611
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
> to fail since it tries to use this constructor:
> {{org.apache.log4j.spi.LoggingEvent.(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
> It is used here (line 117):
> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-400) Provide Appender-Bundles
[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984125#comment-13984125
]
Łukasz Dywicki commented on LOG4J2-400:
---
4.3.0 is sufficient and widely used. 5.0.0 brings some new features but so far
they are not important from log4j point of view.
> Provide Appender-Bundles
>
>
> Key: LOG4J2-400
> URL: https://issues.apache.org/jira/browse/LOG4J2-400
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders, Core
>Affects Versions: 2.0-beta9, 2.0-rc1
> Environment: OSGi R4 / R5 (Apache Felix 4.x)
>Reporter: Roland Weiglhofer
>Priority: Critical
> Labels: Appender, Core, Dependency, OSGi, PluginManager,
> lightweight, optional
> Fix For: 2.0
>
> Attachments: Unbenannt.jpg
>
>
> Instead of deploying all appenders in the core fragment, it would be much
> better if the customer can choose which appender he wants to provide. (I want
> a lightweight version without database and http stuff. I do not want to
> install libraries, which I do not need. All the (transitiv)
> log4j2-dependencies together are much bigger than my own application.)
> It's easy to hive the appender off in a separate bundle fragment. The host
> bundle is the API bundle. The Plugin Manager (core fragment) finds the
> deployed appenders in the classpath of the host bundle. The PluginManager
> should parse the class path in a separate thread (Startup-Hook) and only once
> at the start of the host bundle, but not for each call (when a consumer
> bundle aquires a logger). Make package-imports optional
> (*;resolution:=optional)
> This reduces the number of dependencies and reduces the startup time of the
> whole system.
> One possible solution for the Plugin Manager is to use the reflections plugin
> during the maven build process. This plugin lists all classes of a project
> within a xml file. This file can be marked as a bundle resource and is stored
> within the appender bundle fragment. The idea is that each appender fragment
> has its own class list. Because the bundle host (log4j2 core) sees all
> resources of its fragments it can load these class lists at runtime. Thus,
> the Plugin Manager gets only those appenders that are installed within
> deployed bundle fragements. The class list is created during the build
> process, the plugin manager must not parse the classpath at runtime. Log4j2
> uses a xml parser by default. An additional new dependency to a xml-parser
> library is not required.
>
> org.reflections
> reflections-maven
> 0.9.8
>
>
>
> reflections
>
> process-classes
>
>
>
>
> ${project.basedir}/META-INF/reflections/${project.artifactId}-reflections.xml
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-252) SMTPAppender: send multiple events in one mail
[ https://issues.apache.org/jira/browse/LOG4J2-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984163#comment-13984163 ] Matej Vitásek commented on LOG4J2-252: -- Any idea whether this is considered for implementation? Any workarounds? > SMTPAppender: send multiple events in one mail > -- > > Key: LOG4J2-252 > URL: https://issues.apache.org/jira/browse/LOG4J2-252 > Project: Log4j 2 > Issue Type: Wish >Reporter: Matej Vitásek > > I am using Log4j 2 for a Tomcat web application to send me an e-mail whenever > an ERROR occurs. Usually, more than one error is produced at one time, and I > get a lot of e-mails over a period of a few seconds. > It would be great if the SMTPAppender could cluster more events into one > mail. Of course, one has to be sure that Log4j 2 is not waiting too long to > send me the errors, which could be solved by a timeout setting. > So I propose the following: add a new timeout setting to the SMTPAppender. > Whenever an event that would trigger sending a mail occurs, wait for timeout > seconds and bundle whatever else events occur into this mail. Only then send > the mail. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
Mikael Ståldal created LOG4J2-623:
-
Summary: Better structure of Thread Context Map in JSONLayout
Key: LOG4J2-623
URL: https://issues.apache.org/jira/browse/LOG4J2-623
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
Currently, the Thread Context Map looks like this in JSONLayout:
{quote}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{quote}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it "mdc" rather than the quite vauge "Properties"?
{quote}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code:JavaScript}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code:JavaScript}
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code:JavaScript}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code:JavaScript}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code:JavaScript}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{quote}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{quote}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why name
it "mdc" rather than the quite vauge "Properties"?
{quote}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{quote}
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code:JavaScript}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why name
> it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code:JavaScript}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title="Current"}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript|title="Suggested"}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code:JavaScript}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code:JavaScript}
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title="Current"}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title="Suggested"}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Description:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title=Current}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript|title=Suggested}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code}
was:
Currently, the Thread Context Map looks like this in JSONLayout:
{code:JavaScript|title="Current"}
"Properties":[
{
"name":"UserName",
"value":"admin"
},
{
"name":"OrgName",
"value":"test"
}
]
{code}
This does not properly make use of the JSON data format. Since the Thread
Context Map is a map, it should be represented as a JSON object. And why not
name it "mdc" rather than the quite vauge "Properties"?
{code:JavaScript|title="Suggested"}
"mdc": {
"UserName":"admin",
"OrgName":"test"
}
{code}
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-624) Better structure of Thread Context Stack in JSONLayout
Mikael Ståldal created LOG4J2-624:
-
Summary: Better structure of Thread Context Stack in JSONLayout
Key: LOG4J2-624
URL: https://issues.apache.org/jira/browse/LOG4J2-624
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The Thread Context Stack is currently represented like this in JSONLayout:
{code:JavaScript:title=Current}
"ndc":[foo, bar]"
{code}
This is not correct JSON syntax, and does not make proper use of the JSON data
format. The Thread Context Stack should be represented as a JSON array:
{code:JavaScript:title=Suggested}
"ndc": ["foo", "bar"]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-624) Better structure of Thread Context Stack in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-624:
--
Description:
The Thread Context Stack is currently represented like this in JSONLayout:
{code:JavaScript|title=Current}
"ndc":[foo, bar]"
{code}
This is not correct JSON syntax, and does not make proper use of the JSON data
format. The Thread Context Stack should be represented as a JSON array:
{code:JavaScript|title=Suggested}
"ndc": ["foo", "bar"]
{code}
was:
The Thread Context Stack is currently represented like this in JSONLayout:
{code:JavaScript:title=Current}
"ndc":[foo, bar]"
{code}
This is not correct JSON syntax, and does not make proper use of the JSON data
format. The Thread Context Stack should be represented as a JSON array:
{code:JavaScript:title=Suggested}
"ndc": ["foo", "bar"]
{code}
> Better structure of Thread Context Stack in JSONLayout
> --
>
> Key: LOG4J2-624
> URL: https://issues.apache.org/jira/browse/LOG4J2-624
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Priority: Minor
>
> The Thread Context Stack is currently represented like this in JSONLayout:
> {code:JavaScript|title=Current}
> "ndc":[foo, bar]"
> {code}
> This is not correct JSON syntax, and does not make proper use of the JSON
> data format. The Thread Context Stack should be represented as a JSON array:
> {code:JavaScript|title=Suggested}
> "ndc": ["foo", "bar"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-627) Better structure of Thread Context Stack in XMLLayout
Mikael Ståldal created LOG4J2-627:
-
Summary: Better structure of Thread Context Stack in XMLLayout
Key: LOG4J2-627
URL: https://issues.apache.org/jira/browse/LOG4J2-627
Project: Log4j 2
Issue Type: Improvement
Components: Layouts
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The Thread Context Stack is currently represented like this in XMLLayout:
{code:xml|title=Current}
{code}
This does not make proper use of the XML data format.
{code:xml|title=Suggested}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985647#comment-13985647
]
Mikael Ståldal commented on LOG4J2-623:
---
Currently, it does mimic the XMLLayout. This is not a good thing in this case
since JSON and XML have different structures.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985672#comment-13985672
]
Mikael Ståldal commented on LOG4J2-623:
---
Ah, yes then I agree.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995060#comment-13995060
]
Mikael Ståldal commented on LOG4J2-623:
---
The syntax of the generated JSON is invalid, it looks like this:
{code:xml}
{
"logger":"MyLogger",
"timestamp":"1399900017525",
"level":"INFO",
"thread":"qtp18151360-47",
"message":"Doing stuff...",
"Properties": {
"RequesterIp": "127.0.0.1"},
"UserName": "admin"},
"OrgName": "test"}
}
}
{code}
There are superfluous '}' after each property.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Issue Comment Deleted] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-623:
--
Comment: was deleted
(was: The syntax of the generated JSON is invalid, it looks like this:
{code:xml}
{
"logger":"MyLogger",
"timestamp":"1399900017525",
"level":"INFO",
"thread":"qtp18151360-47",
"message":"Doing stuff...",
"Properties": {
"RequesterIp": "127.0.0.1"},
"UserName": "admin"},
"OrgName": "test"}
}
}
{code}
There are superfluous '}' after each property.
)
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reopened LOG4J2-623:
---
The syntax of the generated JSON is invalid, it looks like this:
{code:xml}
{
"logger":"MyLogger",
"timestamp":"1399900017525",
"level":"INFO",
"thread":"qtp18151360-47",
"message":"Doing stuff...",
"Properties": {
"RequesterIp": "127.0.0.1"},
"UserName": "admin"},
"OrgName": "test"}
}
}
{code}
There are superfluous '}' after each property.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995115#comment-13995115
]
Mikael Ståldal commented on LOG4J2-623:
---
Can you give a concrete example of what the JSON will look like?
It is not sufficient to say that it will be "equivalent" to the XML format,
since JSON and XML are structurally different.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal closed LOG4J2-623.
-
Now I get this:
{code}
{
"logger":"MyLogger",
"timestamp":"1399907141921",
"level":"INFO",
"thread":"qtp18151360-47",
"message":"Doing stuff...",
"Properties": {
"RequesterIp": "127.0.0.1",
"UserName": "admin",
"OrgName": "test"
}
}
{code}
Which is correct and expected. Closing this issue.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996195#comment-13996195
]
Mikael Ståldal commented on LOG4J2-623:
---
Why are you going to undo the improvement to the context map?
(I don't care if the context map is named "contextMap", "mdc" or "Properties".)
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996210#comment-13996210
]
Mikael Ståldal commented on LOG4J2-623:
---
marker now looks like this:
{code}
"marker": {
"name": "Marker1",
"parents": [{
"name": "ParentMarker1"
}, {
"name": "ParentMarker2"
}]
},
{code}
perhaps it can be simplified to this:
{code}
"marker": ["Marker1", "ParentMarker1", "ParentMarker2"],
{code}
It will then be similar in structure to contextStack.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996214#comment-13996214
]
Mikael Ståldal commented on LOG4J2-623:
---
About JSON schema for the contextMap, can't you just declare it as "type":
"object"?
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997357#comment-13997357
]
Mikael Ståldal commented on LOG4J2-623:
---
I did not know that markers support multiple inheritance, since the current
documentation says that they don't:
http://logging.apache.org/log4j/2.x/manual/markers.html
http://logging.apache.org/log4j/2.x/log4j-api/apidocs/index.html
But I see now that this has changed in the latest code in SVN. So forget about
my comment about markers.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997380#comment-13997380
]
Mikael Ståldal commented on LOG4J2-623:
---
The latest code from SVN does not seem to work, I get this error when trying to
use JSONLayout:
java.lang.NoClassDefFoundError:
com/fasterxml/jackson/core/JsonProcessingException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
at java.lang.Class.privateGetPublicMethods(Class.java:2651)
at java.lang.Class.getMethods(Class.java:1467)
at
org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.withFactoryMethodAnnotatedBy(PluginBuilder.java:87)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:710)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:665)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:657)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:657)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:334)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:156)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:380)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:427)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:164)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:73)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:35)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:268)
at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
at org.apache.log4j.Logger.getLogger(Logger.java:41)
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997734#comment-13997734
]
Mikael Ståldal commented on LOG4J2-623:
---
Then you need to clearly document when those Jackson dependencies are needed,
since you cannot expect a regular Log4j user to know that.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997677#comment-13997677
]
Mikael Ståldal commented on LOG4J2-623:
---
I use an XML configuration file, and JSONLayout.
I don't use Jackson in my app, so my app's POM doesn't say anything about it.
And why should it? The use of Jackson is an implementation detail of Log4j that
the user shouldn't need to care about, isn't it?
(BTW, I use Gradle and not Maven for building my app.)
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997697#comment-13997697
]
Mikael Ståldal commented on LOG4J2-623:
---
Now I get this problem instead, probably not related to JSONLayout:
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.logging.log4j.web.Log4jWebInitializerImpl
at java.lang.Class.forName0(Native Method) ~[?:1.7.0_51]
at java.lang.Class.forName(Class.java:270) ~[?:1.7.0_51]
at
org.apache.logging.log4j.core.util.Loader.initializeClass(Loader.java:272)
~[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.ThrowableProxy.loadClass(ThrowableProxy.java:483)
~[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.ThrowableProxy.toExtendedStackTrace(ThrowableProxy.java:595)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.ThrowableProxy.(ThrowableProxy.java:145)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:121)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:97)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.impl.DefaultLogEventFactory.createEvent(DefaultLogEventFactory.java:49)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at
org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:103)
[log4j-core-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
at org.apache.logging.slf4j.Log4jLogger.log(Log4jLogger.java:374)
[log4j-slf4j-impl-2.0-rc2-SNAPSHOT.jar:2.0-rc2-SNAPSHOT]
I have declared dependency to log4j-web. I think that the class
org.apache.logging.log4j.web.Log4jWebInitializerImplis found, but fails to
initialize for some reason.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997687#comment-13997687
]
Mikael Ståldal commented on LOG4J2-623:
---
I tried to remove the true from jackson-core in
log4j-core, just to find out the the same issue applies to jackson-databind.
After removing true from jackson-databind as well,
JSONLayout works.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-623) Better structure of Thread Context Map in JSONLayout
[
https://issues.apache.org/jira/browse/LOG4J2-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13999668#comment-13999668
]
Mikael Ståldal commented on LOG4J2-623:
---
But how is the poor Log4j user supposed to know that he/she needs to include
Jackson dependencies in his/her project in order to get JSONLayout to work?
That user may not even know what Jackson is.
> Better structure of Thread Context Map in JSONLayout
>
>
> Key: LOG4J2-623
> URL: https://issues.apache.org/jira/browse/LOG4J2-623
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Affects Versions: 2.0-rc1
>Reporter: Mikael Ståldal
>Assignee: Ralph Goers
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Currently, the Thread Context Map looks like this in JSONLayout:
> {code:JavaScript|title=Current}
> "Properties":[
> {
> "name":"UserName",
> "value":"admin"
> },
> {
> "name":"OrgName",
> "value":"test"
> }
> ]
> {code}
> This does not properly make use of the JSON data format. Since the Thread
> Context Map is a map, it should be represented as a JSON object. And why not
> name it "mdc" rather than the quite vauge "Properties"?
> {code:JavaScript|title=Suggested}
> "mdc": {
> "UserName":"admin",
> "OrgName":"test"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1161) Builder like pattern to add values to MapMessage
[
https://issues.apache.org/jira/browse/LOG4J2-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528758#comment-15528758
]
Mikael Ståldal commented on LOG4J2-1161:
Yes.
> Builder like pattern to add values to MapMessage
>
>
> Key: LOG4J2-1161
> URL: https://issues.apache.org/jira/browse/LOG4J2-1161
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.4.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>Priority: Minor
>
> It would be nice to have a builder like pattern to add values to
> {{MapMessage}} and its subclass {{StructuredDataMessage}}, so you can do
> {code}
> EventLogger.logEvent(
> new StructuredDataMessage(confirm, null, "transfer")
> .withValue("toAccount", toAccount)
> .withValue("fromAccount", fromAccount)
> .withValue("amount", amount)
> );
> {code}
> instead of
> {code}
> StructuredDataMessage msg = new StructuredDataMessage(confirm, null,
> "transfer");
> msg.put("toAccount", toAccount);
> msg.put("fromAccount", fromAccount);
> msg.put("amount", amount);
> EventLogger.logEvent(msg);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-1161) Builder like pattern to add values to MapMessage
[
https://issues.apache.org/jira/browse/LOG4J2-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reopened LOG4J2-1161:
> Builder like pattern to add values to MapMessage
>
>
> Key: LOG4J2-1161
> URL: https://issues.apache.org/jira/browse/LOG4J2-1161
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.4.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>Priority: Minor
>
> It would be nice to have a builder like pattern to add values to
> {{MapMessage}} and its subclass {{StructuredDataMessage}}, so you can do
> {code}
> EventLogger.logEvent(
> new StructuredDataMessage(confirm, null, "transfer")
> .withValue("toAccount", toAccount)
> .withValue("fromAccount", fromAccount)
> .withValue("amount", amount)
> );
> {code}
> instead of
> {code}
> StructuredDataMessage msg = new StructuredDataMessage(confirm, null,
> "transfer");
> msg.put("toAccount", toAccount);
> msg.put("fromAccount", fromAccount);
> msg.put("amount", amount);
> EventLogger.logEvent(msg);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1161) Builder like pattern to add values to MapMessage
[
https://issues.apache.org/jira/browse/LOG4J2-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal closed LOG4J2-1161.
--
> Builder like pattern to add values to MapMessage
>
>
> Key: LOG4J2-1161
> URL: https://issues.apache.org/jira/browse/LOG4J2-1161
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.4.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.5
>
>
> It would be nice to have a builder like pattern to add values to
> {{MapMessage}} and its subclass {{StructuredDataMessage}}, so you can do
> {code}
> EventLogger.logEvent(
> new StructuredDataMessage(confirm, null, "transfer")
> .withValue("toAccount", toAccount)
> .withValue("fromAccount", fromAccount)
> .withValue("amount", amount)
> );
> {code}
> instead of
> {code}
> StructuredDataMessage msg = new StructuredDataMessage(confirm, null,
> "transfer");
> msg.put("toAccount", toAccount);
> msg.put("fromAccount", fromAccount);
> msg.put("amount", amount);
> EventLogger.logEvent(msg);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1161) Builder like pattern to add values to MapMessage
[
https://issues.apache.org/jira/browse/LOG4J2-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal resolved LOG4J2-1161.
Resolution: Fixed
> Builder like pattern to add values to MapMessage
>
>
> Key: LOG4J2-1161
> URL: https://issues.apache.org/jira/browse/LOG4J2-1161
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.4.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.5
>
>
> It would be nice to have a builder like pattern to add values to
> {{MapMessage}} and its subclass {{StructuredDataMessage}}, so you can do
> {code}
> EventLogger.logEvent(
> new StructuredDataMessage(confirm, null, "transfer")
> .withValue("toAccount", toAccount)
> .withValue("fromAccount", fromAccount)
> .withValue("amount", amount)
> );
> {code}
> instead of
> {code}
> StructuredDataMessage msg = new StructuredDataMessage(confirm, null,
> "transfer");
> msg.put("toAccount", toAccount);
> msg.put("fromAccount", fromAccount);
> msg.put("amount", amount);
> EventLogger.logEvent(msg);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1161) Builder like pattern to add values to MapMessage
[
https://issues.apache.org/jira/browse/LOG4J2-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-1161:
---
Fix Version/s: 2.5
> Builder like pattern to add values to MapMessage
>
>
> Key: LOG4J2-1161
> URL: https://issues.apache.org/jira/browse/LOG4J2-1161
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.4.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.5
>
>
> It would be nice to have a builder like pattern to add values to
> {{MapMessage}} and its subclass {{StructuredDataMessage}}, so you can do
> {code}
> EventLogger.logEvent(
> new StructuredDataMessage(confirm, null, "transfer")
> .withValue("toAccount", toAccount)
> .withValue("fromAccount", fromAccount)
> .withValue("amount", amount)
> );
> {code}
> instead of
> {code}
> StructuredDataMessage msg = new StructuredDataMessage(confirm, null,
> "transfer");
> msg.put("toAccount", toAccount);
> msg.put("fromAccount", fromAccount);
> msg.put("amount", amount);
> EventLogger.logEvent(msg);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1390) Remove workaround for Kafka close timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528831#comment-15528831 ] Mikael Ståldal commented on LOG4J2-1390: Not really since this issue is not fixed, it is postponed. > Remove workaround for Kafka close timeout > - > > Key: LOG4J2-1390 > URL: https://issues.apache.org/jira/browse/LOG4J2-1390 > Project: Log4j 2 > Issue Type: Task > Components: Appenders >Affects Versions: 2.5, 2.6, 2.6.1 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Minor > > The Kafka appender contains a workaround for an issue in the Kafka client > library: https://issues.apache.org/jira/browse/KAFKA-1660 > Now when that Kafka issue is solved, and we use the latest version of the > Kafka client library, we should remove this workaround. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1395) Add "direct" option to ConsoleAppender for increased performance
[ https://issues.apache.org/jira/browse/LOG4J2-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528837#comment-15528837 ] Mikael Ståldal commented on LOG4J2-1395: Yes. > Add "direct" option to ConsoleAppender for increased performance > > > Key: LOG4J2-1395 > URL: https://issues.apache.org/jira/browse/LOG4J2-1395 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.5, 2.6, 2.6.1 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > Fix For: 2.7 > > Attachments: app.zip, ggregory-hardware.txt > > > The ConsoleAppender is much slower than the FileAppender. > It would be nice to improve the performance of the ConsoleAppender. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1395) Add "direct" option to ConsoleAppender for increased performance
[ https://issues.apache.org/jira/browse/LOG4J2-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528840#comment-15528840 ] Mikael Ståldal commented on LOG4J2-1395: I still don't think this is an issue with the ConsoleAppender. Maybe [~rem...@yahoo.com] can help us sort it out? > Add "direct" option to ConsoleAppender for increased performance > > > Key: LOG4J2-1395 > URL: https://issues.apache.org/jira/browse/LOG4J2-1395 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.5, 2.6, 2.6.1 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > Fix For: 2.7 > > Attachments: app.zip, ggregory-hardware.txt > > > The ConsoleAppender is much slower than the FileAppender. > It would be nice to improve the performance of the ConsoleAppender. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1617) PatternLayout Exception handling with filter
Zoltán Nébli created LOG4J2-1617:
Summary: PatternLayout Exception handling with filter
Key: LOG4J2-1617
URL: https://issues.apache.org/jira/browse/LOG4J2-1617
Project: Log4j 2
Issue Type: Bug
Components: Layouts, Pattern Converters
Affects Versions: 2.6.2
Environment: Eclipse mars 4.5.2
jdk 1.8.77
mvn 3.2.1
testng 6.9.10
Reporter: Zoltán Nébli
I am using log4j2 with this 2 dependencies:
org.apache.logging.log4j
log4j-core
2.6.2
org.apache.logging.log4j
log4j-1.2-api
2.6.2
When I try to log for example an error with a throwable like:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.testng.annotations.Test;
public class Test {
private static final Logger logger = LogManager.getLogger(Test.class);
@Test
public void testSendMessage() throws Exception {
Exception exception = new Exception("some exception");
logger.error("error with exception", exception);
}
}
using patternlayout:
org.testng,org.apache.maven,sun.reflect,java.lang.reflect
Then the filtered packages won't disappear from the stacktrace, I can't even
manipulate the stacktrace in any way like maximizing the lines:
%xEx{5}
Output:
2016-09-28 16:16:08,912 [ERROR] myClasspath.Test:20 - error with exception
java.lang.Exception: some exception
at myClasspath.Test... java.lang.Exception: some exception
at myClasspath.Test.testSendMessage(Test.java:19) [test-classes/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.7.0_79]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
~[?:1.7.0_79]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.7.0_79]
at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_79]
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
[testng-6.9.10.jar:?]
at
org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:197)
[testng-6.9.10.jar:?]
at
org.springframework.test.context.testng.AbstractTestNGSpringContextTests.run(AbstractTestNGSpringContextTests.java:175)
[spring-test-4.2.3.RELEASE.jar:4.2.3.RELEASE]
at
org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:209)
[testng-6.9.10.jar:?]
at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
[testng-6.9.10.jar:?]
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:820)
[testng-6.9.10.jar:?]
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1128)
[testng-6.9.10.jar:?]
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129)
[testng-6.9.10.jar:?]
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
[testng-6.9.10.jar:?]
at org.testng.TestRunner.privateRun(TestRunner.java:782)
[testng-6.9.10.jar:?]
at org.testng.TestRunner.run(TestRunner.java:632) [testng-6.9.10.jar:?]
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
[testng-6.9.10.jar:?]
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
[testng-6.9.10.jar:?]
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
[testng-6.9.10.jar:?]
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
[testng-6.9.10.jar:?]
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
[testng-6.9.10.jar:?]
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
[testng-6.9.10.jar:?]
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
[testng-6.9.10.jar:?]
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
[testng-6.9.10.jar:?]
at org.testng.TestNG.run(TestNG.java:1064) [testng-6.9.10.jar:?]
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:113)
[testng-6.9.10.jar:?]
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:206)
[testng-6.9.10.jar:?]
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:177)
[testng-6.9.10.jar:?]
PASSED: testSendMessage
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1623) Configurable JVM shutdown hook timeout
Mikael Ståldal created LOG4J2-1623: -- Summary: Configurable JVM shutdown hook timeout Key: LOG4J2-1623 URL: https://issues.apache.org/jira/browse/LOG4J2-1623 Project: Log4j 2 Issue Type: New Feature Components: Configurators, Core Affects Versions: 2.7 Reporter: Mikael Ståldal Now when it is possible to specify timeout when stopping a LoggingContext (LOG4J2-1539), it would be nice to be able to configure the timeout for the JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1624) KafkaAppender get shutdown timeout 0
Mikael Ståldal created LOG4J2-1624: -- Summary: KafkaAppender get shutdown timeout 0 Key: LOG4J2-1624 URL: https://issues.apache.org/jira/browse/LOG4J2-1624 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.7 Reporter: Mikael Ståldal Assignee: Mikael Ståldal Priority: Blocker -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1625) FlumeAppender get shutdown timeout 0
Mikael Ståldal created LOG4J2-1625: -- Summary: FlumeAppender get shutdown timeout 0 Key: LOG4J2-1625 URL: https://issues.apache.org/jira/browse/LOG4J2-1625 Project: Log4j 2 Issue Type: Bug Components: Flume Appender Affects Versions: 2.7 Reporter: Mikael Ståldal Assignee: Mikael Ståldal Priority: Blocker -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1624) KafkaAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal resolved LOG4J2-1624. Resolution: Fixed > KafkaAppender get shutdown timeout 0 > > > Key: LOG4J2-1624 > URL: https://issues.apache.org/jira/browse/LOG4J2-1624 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1624) KafkaAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1624: --- Fix Version/s: 2.7 > KafkaAppender get shutdown timeout 0 > > > Key: LOG4J2-1624 > URL: https://issues.apache.org/jira/browse/LOG4J2-1624 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1625) FlumeAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal resolved LOG4J2-1625. Resolution: Fixed > FlumeAppender get shutdown timeout 0 > > > Key: LOG4J2-1625 > URL: https://issues.apache.org/jira/browse/LOG4J2-1625 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1625) FlumeAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1625: --- Fix Version/s: 2.7 > FlumeAppender get shutdown timeout 0 > > > Key: LOG4J2-1625 > URL: https://issues.apache.org/jira/browse/LOG4J2-1625 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1623) Configurable JVM shutdown hook timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1623: --- Issue Type: Improvement (was: New Feature) > Configurable JVM shutdown hook timeout > -- > > Key: LOG4J2-1623 > URL: https://issues.apache.org/jira/browse/LOG4J2-1623 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators, Core >Affects Versions: 2.7 >Reporter: Mikael Ståldal > > Now when it is possible to specify timeout when stopping a LoggingContext > (LOG4J2-1539), it would be nice to be able to configure the timeout for the > JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1626) Port Windows Event Log Appender from Log4j 1.2
[ https://issues.apache.org/jira/browse/LOG4J2-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535382#comment-15535382 ] Mikael Ståldal commented on LOG4J2-1626: I don't use Windows either. > Port Windows Event Log Appender from Log4j 1.2 > -- > > Key: LOG4J2-1626 > URL: https://issues.apache.org/jira/browse/LOG4J2-1626 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Reporter: Gary Gregory >Assignee: Gary Gregory > > Log4j 1.2 had an Windows Event Log Appender event log appender. Port it to > Log4j 2. This was the NTEventLogAppender and associated DLL. Provide both a > 32-bit and 64-bit DLL. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1588) Console or File Logger caches thread name, but not in older log4j2 versions
[
https://issues.apache.org/jira/browse/LOG4J2-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15535875#comment-15535875
]
Mikael Ståldal commented on LOG4J2-1588:
Maybe you can use Thread Content Map (also known as MDC) instead:
http://logging.apache.org/log4j/2.x/manual/thread-context.html
Use the {{%X}} pattern instead of {{%t}}.
> Console or File Logger caches thread name, but not in older log4j2 versions
> ---
>
> Key: LOG4J2-1588
> URL: https://issues.apache.org/jira/browse/LOG4J2-1588
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.6.2
> Environment: Windows, Grizzly HTTP container, SLF4J API, Log4j2
>Reporter: Rainer Schnitker
>
> Log4j2 2.6.x seems to cache the thread name. A revert to version 2.4.1.
> works! This affects synchronous logger: console, RollingFile
> My sample code (JAX-RS Filter):
> {code}
> import java.io.IOException;
> import javax.annotation.Priority;
> import javax.inject.Inject;
> import javax.ws.rs.container.ContainerRequestContext;
> import javax.ws.rs.container.ContainerRequestFilter;
> import javax.ws.rs.ext.Provider;
> import org.glassfish.grizzly.http.server.Request;
> import org.slf4j.LoggerFactory;
> @Provider
> @Priority(Integer.MIN_VALUE)
> public class GrizzlyRequestFilter implements ContainerRequestFilter {
> @Inject
> javax.inject.Provider< Request > provider;
> @Override
> public void filter( ContainerRequestContext requestContext ) throws
> IOException {
> Request request = this.provider.get();
> Thread thread = Thread.currentThread();
> thread.setName( request.getRemoteHost() + '/' + thread.getId() );
>
> // oops: logger thread name != expected
> LoggerFactory.getLogger(GrizzlyRequestFilter.class)
> .info( "expected thread name:" + request.getRemoteHost() + '/' +
> thread.getId() );
>
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1627) Move components from the Log4j 2 build into a separate build.
[ https://issues.apache.org/jira/browse/LOG4J2-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15541863#comment-15541863 ] Mikael Ståldal commented on LOG4J2-1627: If we should reorganize the project, there is another issue we should consider: transitive dependencies Currently, log4j-core has quite some optional dependencies. I don't like that since the user needs to manually keep track of which transitive runtime dependencies to use, efficiently negating the advantage of using Maven (or Ivy, Gradle, SBT) in the first place. If we should split up log4j-core, then I would like to move out everything that have transitive dependencies to their own modules, and make those dependencies non-optional in those new modules. > Move components from the Log4j 2 build into a separate build. > - > > Key: LOG4J2-1627 > URL: https://issues.apache.org/jira/browse/LOG4J2-1627 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Ralph Goers > > The Log4j build has grown to the point that performing releases is very time > consuming. One way to help with this is to move some components, especially > those that are not typically modified frequently, to another project. Almost > everything besides the API, Core, web and the various bridges could be moved. > In addition, some core components could be considered for moving to another > module such as the mom and db appenders. Perhaps even the JMX support could > be moved. > We should also take into consideration making things line up with the Java > profile system in Java 8 and the Java 9 module system. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1625) FlumeAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal closed LOG4J2-1625. -- > FlumeAppender get shutdown timeout 0 > > > Key: LOG4J2-1625 > URL: https://issues.apache.org/jira/browse/LOG4J2-1625 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1624) KafkaAppender get shutdown timeout 0
[ https://issues.apache.org/jira/browse/LOG4J2-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal closed LOG4J2-1624. -- > KafkaAppender get shutdown timeout 0 > > > Key: LOG4J2-1624 > URL: https://issues.apache.org/jira/browse/LOG4J2-1624 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal >Priority: Blocker > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1623) Configurable JVM shutdown hook timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal reassigned LOG4J2-1623: -- Assignee: Mikael Ståldal > Configurable JVM shutdown hook timeout > -- > > Key: LOG4J2-1623 > URL: https://issues.apache.org/jira/browse/LOG4J2-1623 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators, Core >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > > Now when it is possible to specify timeout when stopping a LoggingContext > (LOG4J2-1539), it would be nice to be able to configure the timeout for the > JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1623) Configurable JVM shutdown hook timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542854#comment-15542854 ] Mikael Ståldal commented on LOG4J2-1623: Work in progress in Git branch LOG4J2-1623. > Configurable JVM shutdown hook timeout > -- > > Key: LOG4J2-1623 > URL: https://issues.apache.org/jira/browse/LOG4J2-1623 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators, Core >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > > Now when it is possible to specify timeout when stopping a LoggingContext > (LOG4J2-1539), it would be nice to be able to configure the timeout for the > JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1629) Support for primitive values in StringMap
[
https://issues.apache.org/jira/browse/LOG4J2-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15544708#comment-15544708
]
Mikael Ståldal commented on LOG4J2-1629:
Why not {{LongBiConsumer}} / {{LongTriConsumer}} instad of {{LongConsumer}} /
{{LongObjConsumer}} ?
> Support for primitive values in StringMap
> -
>
> Key: LOG4J2-1629
> URL: https://issues.apache.org/jira/browse/LOG4J2-1629
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.7
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> For some applications like financial trading systems, highly interactive
> games or numerical computation-heavy scientific applications, a large portion
> of data is stored in primitives. Applications like this sometimes need to set
> such values in the logging context (e.g., order ID, algo strategy instance
> ID, etc) and would prefer to avoid the overhead of boxing/unboxing these
> primitives.
> Building on top of the work done for LOG4J2-1447 and LOG4J2-1349, this ticket
> proposes to add interfaces extending ThreadContextMap2, StringMap and
> ReadOnlyStringMap to add support for primitive values:
> {code}
> public interface ThreadContextMap3 extends ThreadContextMap2 {
> long getLong(String key);
> void putLong(String key, long value);
> boolean containsLong(String key);
> /** The value {@link #getLong()} should return if the map
> * doesn't have a long value for the specified key.
> */
> long getDefaultLong();
> void setDefaultLong(long defaultValue);
> }
> {code}
> {code}
> public interface ReadOnlyHybridStringMap extends ReadOnlyStringMap {
> long getLong(String key);
> boolean containsLong(String key);
> long getDefaultLong();
> void setDefaultLong(long defaultValue);
> void forEach(HybridBiConsumer action);
> void forEach(HybridTriConsumer action);
> }
> {code}
> {code}
> public interface HybridStringMap extends StringMap {
> void putLong(String key, long value);
> }
> {code}
> The semantics remain the same as a normal map: there is at most one value for
> a key. Putting a value with the same key replaces the old value with that
> key, regardless of whether the old value was an Object or a primitive.
> An API supporting only primitive long values is sufficient because all
> primitives can be represented as a 64 bit long. For example, a double can be
> converted to a long and back with the {{Double.doubleToLongBits(double)}}
> method and its reverse. Applications can decorate the Log4j interfaces with
> custom facades that provide separate methods for different primitive types if
> required.
> For iteration, new interfaces StringLongConsumer and StringLongObjConsumer
> are introduced. These interfaces are similar to the previous Consumer
> interfaces except that their {{accept}} method takes a {{long}} parameter for
> the value:
> {code}
> public interface StringLongConsumer {
> /**
> * Performs the operation given the specified arguments.
> * @param key the first input argument
> * @param longValue the second input argument as a primitive long, or
> * a default value if the underlying value is not a
> primitive value
> */
> void accept(K key, long longValue);
> }
> public interface StringLongObjConsumer {
> void accept(String key, long value, T state);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1623) Configurable JVM shutdown hook timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15551707#comment-15551707 ] Mikael Ståldal commented on LOG4J2-1623: I think this is done now, what do you think [~garydgregory]? > Configurable JVM shutdown hook timeout > -- > > Key: LOG4J2-1623 > URL: https://issues.apache.org/jira/browse/LOG4J2-1623 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators, Core >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > > Now when it is possible to specify timeout when stopping a LoggingContext > (LOG4J2-1539), it would be nice to be able to configure the timeout for the > JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554892#comment-15554892 ] Mikael Ståldal commented on LOG4J2-1630: I think we should use the more OO way, then it will be an implementation detail whether to use long or String (or something else) to identify them. > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.8 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1630) Unit of Work Logging
[
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554901#comment-15554901
]
Mikael Ståldal commented on LOG4J2-1630:
Maybe the UnitOfWork should be made Closeable so that you can do:
{code}
try (UnitOfWork uow = logger.begin("UOW1")) {
// ...
}
{code}
and {{close()}} would then commit if not already committed, and do nothing if
already committed.
> Unit of Work Logging
>
>
> Key: LOG4J2-1630
> URL: https://issues.apache.org/jira/browse/LOG4J2-1630
> Project: Log4j 2
> Issue Type: Story
> Components: API, Core, Filters
>Affects Versions: 2.7
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> h3. Intent
> Provide a way to filter log events, where the decision on whether to discard
> the message or actually log them cannot be made until after the application
> has already logged the message.
> h3. Motivation
> In many systems, particularly event processing applications, log files
> contain a lot of repetitive log messages. Suppose an application needs to do
> some calculation to decide whether or not to react to some event, and a lot
> of detail is logged during this calculation. Imagine that 99% of the time,
> the application decides to take no action. Once the application arrived at
> that conclusion it would be nice if we could go back and undo all the
> detailed logging and print a summary instead. When the application _does_
> decide to take some action, however, we _do_ want the detailed log messages.
> A Unit of Work for logging would allow us to group a set of log messages and
> either discard them or log them together. (Inspired by Martin Fowler's [Unit
> of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.)
> This should result in log files where a lot of the "uninteresting" logging is
> filtered out, significantly reducing the amount of data logged.
> Some applications do this in an ad hoc manner, for example by passing a
> Collection to its components, where these components can add log message
> strings to this Collection. When the discard/retain decision is made, the
> application then either clears the Collection or logs the contents of the
> Collection. This works, but having to pass the Collection down the component
> tree is clunky and the result often omits details like logger name, timestamp
> and other details that come for free with normal logging. Log4j can provide a
> reusable and less intrusive way to accomplish this.
> h3. How it works
> There would need to be some API for the application to mark the _start_ of
> the unit of work, and some API to signal whether the log messages that are
> part of that unit of work need to be _discarded_ or _logged_ (retained).
> Not all logging that occurs after a unit of work was started is part of that
> unit of work. The application may want some messages to be logged regardless
> of whether the unit of work was discarded or not. There needs to be a
> flexible way (or multiple ways) to include or exclude logging statements from
> the unit of work.
> The application may also designate multiple units of work, which may be
> sequential, nested or partially overlapping. Each unit of work may define its
> own rules for which log messages are considered included in or excluded from
> the unit of work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1560) Log4j can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1250#comment-1250 ] Mikael Ståldal commented on LOG4J2-1560: Is this issue still present in the newly released 2.7? > Log4j can lose exceptions when a security manager is present > > > Key: LOG4J2-1560 > URL: https://issues.apache.org/jira/browse/LOG4J2-1560 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.6.2 >Reporter: Jason Tedor > Attachments: log4j-exception-logging-issue.tar.gz, > throwable-proxy-security-exception-2.6.2.patch > > > When Log4j is rendering an exception, it can attempt to load classes that it > does not have permissions to load when a security manager is present. > I have a patch and a failing test case for this; I will submit it shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1560) Log4j can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1377#comment-1377 ] Mikael Ståldal commented on LOG4J2-1560: I don't understand the difference between this issue and LOG4J2-1563. > Log4j can lose exceptions when a security manager is present > > > Key: LOG4J2-1560 > URL: https://issues.apache.org/jira/browse/LOG4J2-1560 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.6.2 >Reporter: Jason Tedor > Attachments: log4j-exception-logging-issue.tar.gz, > throwable-proxy-security-exception-2.6.2.patch > > > When Log4j is rendering an exception, it can attempt to load classes that it > does not have permissions to load when a security manager is present. > I have a patch and a failing test case for this; I will submit it shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1560) Log4j can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1417#comment-1417 ] Mikael Ståldal commented on LOG4J2-1560: But if the patch is included in LOG4J2-1563 was applied to master before the 2.7 release, shouldn't this issue now be solved in 2.7? Have you tried 2.7? > Log4j can lose exceptions when a security manager is present > > > Key: LOG4J2-1560 > URL: https://issues.apache.org/jira/browse/LOG4J2-1560 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.6.2 >Reporter: Jason Tedor > Attachments: log4j-exception-logging-issue.tar.gz, > throwable-proxy-security-exception-2.6.2.patch > > > When Log4j is rendering an exception, it can attempt to load classes that it > does not have permissions to load when a security manager is present. > I have a patch and a failing test case for this; I will submit it shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15561697#comment-15561697 ] Mikael Ståldal commented on LOG4J2-1630: Sound like making the logging system part of an distributed transaction. > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.8 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1563) Log4j 2.6.2 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15561773#comment-15561773 ] Mikael Ståldal commented on LOG4J2-1563: Maybe we should encourage external contributors to use GitHib pull requests rather than sending patch files? > Log4j 2.6.2 can lose exceptions when a security manager is present > -- > > Key: LOG4J2-1563 > URL: https://issues.apache.org/jira/browse/LOG4J2-1563 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.6.2 >Reporter: Jason Tedor >Assignee: Gary Gregory > Fix For: 2.7 > > Attachments: > 0001-Unify-handling-of-throwables-when-loading-class.patch, > 0002-Remove-policy-in-throwable-proxy-security-test.patch, > throwable-proxy-security-exception-2.6.2.patch > > > When Log4j is rendering an exception, it can attempt to load classes that it > does not have permissions to load when a security manager is present. > I have a patch and a failing test case for this; I will submit it shortly. > This is the backport for LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1634) Root LoggerConfig is corrupted leading to stack overflow
[
https://issues.apache.org/jira/browse/LOG4J2-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-1634:
---
Affects Version/s: 2.7
> Root LoggerConfig is corrupted leading to stack overflow
>
>
> Key: LOG4J2-1634
> URL: https://issues.apache.org/jira/browse/LOG4J2-1634
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6.2, 2.7
>Reporter: Rod Burgett
> Attachments: ReproLoggerConfigBug.java
>
>
> The simple repro code below demonstrates the corruption of the LoggerConfig
> instance for root logger. Executing the main leads to unstopped recursion,
> leading to stack overflow. The recursion includes three method calls, shown
> in this stack trace fragment:
> at
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:381)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:376)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
> The basic problem is that 'logParent' becomes no-op (ends recursion) if
> additivity is off or if logger config's parent is null, otherwise recusrion
> continues.
> In the repro case, the root logger config points to itself as parent.
> I expect that when adding a logger to Configuration, the LoggerConfig should
> be specific to the named logger. So, the stack overflow could be avoided if
> Configuration.addLogger checked that the LoggerConfig's name matched the
> input logger name.
> Repro code:
> String loggerName = "new.logger.name";
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> Configuration config = ctx.getConfiguration();
> LoggerConfig logCfg = config.getLoggerConfig(loggerName);
> config.addLogger(loggerName, logCfg);
> ctx.updateLoggers();
> LogManager.getLogger(loggerName).error("...by: "+loggerName+"");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1623) Configurable JVM shutdown hook timeout
[ https://issues.apache.org/jira/browse/LOG4J2-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal resolved LOG4J2-1623. Resolution: Fixed Fix Version/s: 2.7.1 In Git master. > Configurable JVM shutdown hook timeout > -- > > Key: LOG4J2-1623 > URL: https://issues.apache.org/jira/browse/LOG4J2-1623 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators, Core >Affects Versions: 2.7 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > Fix For: 2.7.1 > > > Now when it is possible to specify timeout when stopping a LoggingContext > (LOG4J2-1539), it would be nice to be able to configure the timeout for the > JVM shutdown hook (currently zero). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1549) AsyncLoggerContextSelector+PropertiesConfigurationBuilder defaults to includeLocation=true
[ https://issues.apache.org/jira/browse/LOG4J2-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal closed LOG4J2-1549. -- This should be fixed in 2.7. > AsyncLoggerContextSelector+PropertiesConfigurationBuilder defaults to > includeLocation=true > -- > > Key: LOG4J2-1549 > URL: https://issues.apache.org/jira/browse/LOG4J2-1549 > Project: Log4j 2 > Issue Type: Bug > Components: Configurators >Reporter: Jason Bedard >Assignee: Mikael Ståldal > Fix For: 2.7 > > > The async documentation seems to indicate that includeLocation=false by > default for [async > loggers/appenders|https://logging.apache.org/log4j/2.x/manual/async.html#Location] > and for the > [all-async|https://logging.apache.org/log4j/2.x/manual/async.html#AllAsync] > When using properties files PropertiesConfigurationBuilder seems to default > to includeLocation=true for the [root > logger|https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/config/properties/PropertiesConfigurationBuilder.java;h=0f159ff3d33f638333e8ca530844d81437db99b5;hb=a493c04c046763140612307400f9189d8f0acd28#l299] > and > [loggers|https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/config/properties/PropertiesConfigurationBuilder.java;h=0f159ff3d33f638333e8ca530844d81437db99b5;hb=a493c04c046763140612307400f9189d8f0acd28#l265], > unless the logger/appender has type=asyncLogger/Appender or you manually > specify includeLocation. > I assume this is specific to properties config but haven't verified that. > Currently using the latest log4j (2.6.2). > Side note: I'm using my own ConfigurationFactory, but it just delegates to > PropertiesConfigurationFactory which uses PropertiesConfigurationBuilder. I > don't think this should effect anything. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1535) KafkaAppender NullPointerException when putting the related jars in tomcat lib
[ https://issues.apache.org/jira/browse/LOG4J2-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582007#comment-15582007 ] Mikael Ståldal commented on LOG4J2-1535: So this issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. > KafkaAppender NullPointerException when putting the related jars in tomcat lib > -- > > Key: LOG4J2-1535 > URL: https://issues.apache.org/jira/browse/LOG4J2-1535 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.6.2 > Environment: Tomcat 7.0.70 >Reporter: Bill Okara > Attachments: kafka-test-src.tar.gz > > > By putting the log4j2 and kafka appender related jars in tomcat/lib (instead > of packaged in WEB-INF/lib), got NullPointerException when initializing the > log4j2.xml. > Steps to reproduce: > 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > > mvn clean package > 2) get all the dependency jars by: > > mvn dependency:copy-dependencies > 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ > 4) deploy the war to tomcat > 5) start tomcat > Will see errors like: > Caused by: java.lang.NullPointerException at > org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) > at > org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) > at > org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) > at > org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1535) KafkaAppender NullPointerException when putting the related jars in tomcat lib
[ https://issues.apache.org/jira/browse/LOG4J2-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1535: --- Description: By putting the log4j2 and kafka appender related jars in tomcat/lib (instead of packaged in WEB-INF/lib), got NullPointerException when initializing the log4j2.xml. Steps to reproduce: 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > mvn clean package 2) get all the dependency jars by: > mvn dependency:copy-dependencies 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ 4) deploy the war to tomcat 5) start tomcat Will see errors like: Caused by: java.lang.NullPointerException at org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) at org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) This issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. was: By putting the log4j2 and kafka appender related jars in tomcat/lib (instead of packaged in WEB-INF/lib), got NullPointerException when initializing the log4j2.xml. Steps to reproduce: 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > mvn clean package 2) get all the dependency jars by: > mvn dependency:copy-dependencies 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ 4) deploy the war to tomcat 5) start tomcat Will see errors like: Caused by: java.lang.NullPointerException at org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) at org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) > KafkaAppender NullPointerException when putting the related jars in tomcat lib > -- > > Key: LOG4J2-1535 > URL: https://issues.apache.org/jira/browse/LOG4J2-1535 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.6.2 > Environment: Tomcat 7.0.70 >Reporter: Bill Okara > Attachments: kafka-test-src.tar.gz > > > By putting the log4j2 and kafka appender related jars in tomcat/lib (instead > of packaged in WEB-INF/lib), got NullPointerException when initializing the > log4j2.xml. > Steps to reproduce: > 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > > mvn clean package > 2) get all the dependency jars by: > > mvn dependency:copy-dependencies > 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ > 4) deploy the war to tomcat > 5) start tomcat > Will see errors like: > Caused by: java.lang.NullPointerException at > org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) > at > org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) > at > org.apache.logging.log4j.core.config.AbstractConfiguration
[jira] [Updated] (LOG4J2-1535) KafkaAppender NullPointerException when putting the related jars in tomcat lib
[ https://issues.apache.org/jira/browse/LOG4J2-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1535: --- Component/s: (was: Appenders) Core > KafkaAppender NullPointerException when putting the related jars in tomcat lib > -- > > Key: LOG4J2-1535 > URL: https://issues.apache.org/jira/browse/LOG4J2-1535 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.6.2 > Environment: Tomcat 7.0.70 >Reporter: Bill Okara > Attachments: kafka-test-src.tar.gz > > > By putting the log4j2 and kafka appender related jars in tomcat/lib (instead > of packaged in WEB-INF/lib), got NullPointerException when initializing the > log4j2.xml. > Steps to reproduce: > 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > > mvn clean package > 2) get all the dependency jars by: > > mvn dependency:copy-dependencies > 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ > 4) deploy the war to tomcat > 5) start tomcat > Will see errors like: > Caused by: java.lang.NullPointerException at > org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) > at > org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) > at > org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) > at > org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) > > This issue is triggered by the fact that the Kafka client library we use > itself does logging via SLF4J during initialization. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1535) KafkaAppender NullPointerException when putting the related jars in tomcat lib
[ https://issues.apache.org/jira/browse/LOG4J2-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikael Ståldal updated LOG4J2-1535: --- Description: By putting the log4j2 and kafka appender related jars in tomcat/lib (instead of packaged in WEB-INF/lib), got NullPointerException when initializing the log4j2.xml. Steps to reproduce: 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > mvn clean package 2) get all the dependency jars by: > mvn dependency:copy-dependencies 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ 4) deploy the war to tomcat 5) start tomcat Will see errors like: Caused by: java.lang.NullPointerException at org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) at org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) So this issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. And in this particular web configuration, org.slf4j.LoggerFactory.getLogger(Class) return null during Configuration.start(). was: By putting the log4j2 and kafka appender related jars in tomcat/lib (instead of packaged in WEB-INF/lib), got NullPointerException when initializing the log4j2.xml. Steps to reproduce: 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > mvn clean package 2) get all the dependency jars by: > mvn dependency:copy-dependencies 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ 4) deploy the war to tomcat 5) start tomcat Will see errors like: Caused by: java.lang.NullPointerException at org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) at org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) at org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) at org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) This issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. > KafkaAppender NullPointerException when putting the related jars in tomcat lib > -- > > Key: LOG4J2-1535 > URL: https://issues.apache.org/jira/browse/LOG4J2-1535 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.6.2 > Environment: Tomcat 7.0.70 >Reporter: Bill Okara > Attachments: kafka-test-src.tar.gz > > > By putting the log4j2 and kafka appender related jars in tomcat/lib (instead > of packaged in WEB-INF/lib), got NullPointerException when initializing the > log4j2.xml. > Steps to reproduce: > 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > > mvn clean package > 2) get all the dependency jars by: > > mvn dependency:copy-dependencies > 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ > 4) deploy the war to tomcat > 5) start tomcat > Will see errors like: > Caused by: java.lang.NullPointerException at > org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) > at > org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFac
[jira] [Comment Edited] (LOG4J2-1535) KafkaAppender NullPointerException when putting the related jars in tomcat lib
[ https://issues.apache.org/jira/browse/LOG4J2-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15582007#comment-15582007 ] Mikael Ståldal edited comment on LOG4J2-1535 at 10/17/16 12:05 PM: --- So this issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. And in this particular web configuration, org.slf4j.LoggerFactory.getLogger(Class) return null during Configuration.start(). was (Author: mikaelstaldal): So this issue is triggered by the fact that the Kafka client library we use itself does logging via SLF4J during initialization. > KafkaAppender NullPointerException when putting the related jars in tomcat lib > -- > > Key: LOG4J2-1535 > URL: https://issues.apache.org/jira/browse/LOG4J2-1535 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.6.2 > Environment: Tomcat 7.0.70 >Reporter: Bill Okara > Attachments: kafka-test-src.tar.gz > > > By putting the log4j2 and kafka appender related jars in tomcat/lib (instead > of packaged in WEB-INF/lib), got NullPointerException when initializing the > log4j2.xml. > Steps to reproduce: > 1) unzip the attached kafka-test-src.tar.gz, build the project with maven: > > mvn clean package > 2) get all the dependency jars by: > > mvn dependency:copy-dependencies > 3) copy the *.jar from $project/target/dependency/*.jar to tomcat/lib/ > 4) deploy the war to tomcat > 5) start tomcat > Will see errors like: > Caused by: java.lang.NullPointerException at > org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:658) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:333) > at > org.apache.kafka.clients.producer.KafkaProducer.(KafkaProducer.java:188) > at > org.apache.logging.log4j.core.appender.mom.kafka.DefaultKafkaProducerFactory.newKafkaProducer(DefaultKafkaProducerFactory.java:29) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaManager.startup(KafkaManager.java:86) > at > org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.start(KafkaAppender.java:96) > at > org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:247) > at > org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:566) > > This issue is triggered by the fact that the Kafka client library we use > itself does logging via SLF4J during initialization. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1642) DefaultShutdownCallbackRegistry throws NoClassDefFoundError
[
https://issues.apache.org/jira/browse/LOG4J2-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584976#comment-15584976
]
Mikael Ståldal commented on LOG4J2-1642:
Not that I am aware of.
> DefaultShutdownCallbackRegistry throws NoClassDefFoundError
> ---
>
> Key: LOG4J2-1642
> URL: https://issues.apache.org/jira/browse/LOG4J2-1642
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
> Environment: java version "1.8.0_60"
> Maven_3.2.2
>Reporter: Johno Crawford
>
> When running the Maven goals for packaging my project an exception is thrown
> when the JVM exits..
> {noformat}
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 01:36 min (Wall Clock)
> [INFO] Finished at: 2016-10-18T12:06:06+03:00
> [INFO] Final Memory: 48M/626M
> [INFO]
>
> Exception in thread "pool-1-thread-1" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/message/ParameterizedMessage
> at
> org.apache.logging.log4j.message.ParameterizedNoReferenceMessageFactory.newMessage(ParameterizedNoReferenceMessageFactory.java:104)
> at
> org.apache.logging.log4j.message.AbstractMessageFactory.newMessage(AbstractMessageFactory.java:75)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2010)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1884)
> at
> org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:793)
> at
> org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry.run(DefaultShutdownCallbackRegistry.java:76)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.message.ParameterizedMessage
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1642) DefaultShutdownCallbackRegistry throws NoClassDefFoundError
[
https://issues.apache.org/jira/browse/LOG4J2-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584983#comment-15584983
]
Mikael Ståldal commented on LOG4J2-1642:
Can you provide some more information on how to reproduce this problem? The
full Maven command line, and preferably a complete Maven project (or at least a
.pom file).
> DefaultShutdownCallbackRegistry throws NoClassDefFoundError
> ---
>
> Key: LOG4J2-1642
> URL: https://issues.apache.org/jira/browse/LOG4J2-1642
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
> Environment: java version "1.8.0_60"
> Maven_3.2.2
>Reporter: Johno Crawford
>
> When running the Maven goals for packaging my project an exception is thrown
> when the JVM exits..
> {noformat}
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 01:36 min (Wall Clock)
> [INFO] Finished at: 2016-10-18T12:06:06+03:00
> [INFO] Final Memory: 48M/626M
> [INFO]
>
> Exception in thread "pool-1-thread-1" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/message/ParameterizedMessage
> at
> org.apache.logging.log4j.message.ParameterizedNoReferenceMessageFactory.newMessage(ParameterizedNoReferenceMessageFactory.java:104)
> at
> org.apache.logging.log4j.message.AbstractMessageFactory.newMessage(AbstractMessageFactory.java:75)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2010)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1884)
> at
> org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:793)
> at
> org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry.run(DefaultShutdownCallbackRegistry.java:76)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.message.ParameterizedMessage
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-424) JDBCAppender: Add support for data types other then String
[ https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585717#comment-15585717 ] Mikael Ståldal commented on LOG4J2-424: --- [~rem...@yahoo.com], can we use the new ContextData for this? > JDBCAppender: Add support for data types other then String > -- > > Key: LOG4J2-424 > URL: https://issues.apache.org/jira/browse/LOG4J2-424 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0-beta9 > Environment: All >Reporter: Tihomir Meščić >Assignee: Nick Williams > > I am using the JDBCAppender to log to a Postgresql database. I have a table > (log_entries) that's used for logging purposes. > One of the attributes is of type INTEGER. The attribute is something specific > for our application and we are using ThreadContext (MDC) to set the value of > the parameter. > Currently, log4j provides no support for integer type attributes in the > Column element of the JDBC appender configuration (the only types supported > are string (default), timestamp - isEventTimestamp flag and Clob - isClob > flag). > When using the default settings in the Column element of the JDBC appender, > log4j will create a prepared statement and try to set the value using the > Statement.setString() method. Of course, the JDBC driver throws an exception: > Caused by: org.postgresql.util.PSQLException: ERROR: column "mn_type_d" is of > type integer but expression is of type character varying > Hint: You will need to rewrite or cast the expression. > My appender configuration: > >username="xxx" password="xxx" /> > > > . > > > <-- this is of type integer in the DB but LOG4J tries to insert it as a > String --> > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
