[jira] [Comment Edited] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917313#comment-13917313
]
Remko Popma edited comment on LOG4J2-555 at 3/2/14 7:21 AM:
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519. EDIT: I overlooked the getter method for this.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
was (Author: rem...@yahoo.com):
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917313#comment-13917313
]
Remko Popma commented on LOG4J2-555:
Interesting! I see the difficulty now: apps may call a method in the subclass
or in AbstractLogger, so any stacktrace-walking should work for both.
If custom loggers _must_ use the {{log(Marker, String, Level, Message,
Throwable)}} method, {{AbstractLogger}} should at least make its
{{MessageFactory}} available to subclasses. The fact that this is not available
was what made me call the other {{log}} methods in the custom logger in
LOG4J2-519.
Still, it seems a bit... fragile to ask subclasses to use only that particular
method. I'll think a bit more if there isn't an alternative. Thanks for the
explanation!
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
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
Bug report for Log4j [2014/03/02]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 4913|Opn|Min|2001-11-16|org.apache.log4j.helpers.FileWatchdog should allow| |13099|Opn|Nor|2002-09-27|DOMConfigurator ignores category factory setting | |17887|Opn|Maj|2003-03-11|RollingFileAppender does not work for 10 threads | |20395|Inf|Enh|2003-06-01|PreparedStatementAppender Enhancement | |23329|New|Enh|2003-09-22| element in XML config should support reso| |26084|Inf|Nor|2004-01-13|Log Event detail panel does not show special chara| |27363|Inf|Enh|2004-03-02|JNI based SyslogAppender | |27367|Inf|Enh|2004-03-02|NetSendAppender | |28059|Opn|Enh|2004-03-30|DOMConfigurator.configure(java.io.InputStream)| |29244|Inf|Nor|2004-05-27|Preserve XML content in log messages when using XM| |29305|New|Nor|2004-05-30|Chainsaw doesn't see locationinfo from XMLSocketRe| |30055|New|Nor|2004-07-12|Problem with registering Appenders with the same n| |30888|Inf|Maj|2004-08-27|Chainsaw mixes files in same panel| |30892|New|Min|2004-08-27|Log files cannot be closed| |31089|New|Nor|2004-09-07|Does not accept ISO8601 dates in focus field | |31178|Inf|Cri|2004-09-11|Exception using Chainsaw for simple debugging | |31179|Ass|Enh|2004-09-11|Implement Chainsaw as Eclipse stand-alone applicat| |33278|New|Min|2005-01-27|NPE thrown durring daily log file rollover| |33493|Inf|Enh|2005-02-10|contribution to log4j: servlet diagnostic context | |34440|New|Nor|2005-04-13|sandbox:IMAppender - comma-seperated recipient lis| |34491|Ver|Nor|2005-04-18|Missing include in build.jms target results in mis| |34651|New|Enh|2005-04-27|allow for a header on top of every rolled file| |34738|Inf|Nor|2005-05-04|Chainsaw does not remember what Columns are select| |34974|Inf|Cri|2005-05-19|Exception when running a Pluglet | |35239|Inf|Nor|2005-06-06|NullPointerException when saving displayed events | |35563|Inf|Enh|2005-06-30|Syslog appender parametrability | |35996|Inf|Enh|2005-08-03|Add support for ant-like in log4j.xml | |36435|New|Enh|2005-08-31|Log4J RollingFileAppender under OpenVMS does not f| |36654|Inf|Min|2005-09-14|Provide better error messages for "Please initiali| |36789|Inf|Nor|2005-09-23|Empty control flow statement in org.apache.log4j.l| |37638|New|Nor|2005-11-25|logging doesn't fall back with FallbackErrorHandle| |37734|New|Nor|2005-12-01|Customize Event ID and Event Category with NTEVent| |38363|Ass|Maj|2006-01-24|SecurityException during log output | |38394|Ver|Enh|2006-01-26|PropertySetter fails to print stacktrace if error | |38395|Ver|Reg|2006-01-26|Unable to set threshold on appender via config fil| |38406|Ver|Nor|2006-01-26|jdk1.4 dependencies in log4j 1.3 alpha| |38513|New|Nor|2006-02-05|[PATCH] Suggested unit test for JMSAppender | |38582|Ass|Nor|2006-02-08|Chainsaw does not include Receiver JavaDoc in dist| |38590|Inf|Nor|2006-02-09|no space on device fails another instance | |38883|Opn|Nor|2006-03-07|LogFilePatternReceiver fails to process multi-line| |39690|Inf|Cri|2006-05-31|Initialization fail in J2EE Environment | |39691|Ass|Nor|2006-05-31|DBAppender doesn't log long events| |40068|New|Nor|2006-07-18|Add support for attach-on-demand API to chainsaw | |40251|Opn|Min|2006-08-14|Hard coded JMX domain name for MBean instances| |40382|Inf|Maj|2006-09-01|Sysappender hangs during boot time on HP | |40385|Inf|Maj|2006-09-01|SocketServer cannot find config file when passed a| |40472|New|Nor|2006-09-11|SettingsManager calls loadSettings with global set| |40533|New|Nor|2006-09-18|Chainsaw not showing all logging statements | |40611|New|Trv|2006-09-27|Bad subclass example; NullPointerException in Logg| |40889|Inf|Nor|2006-11-03|repeated entries in log after failure | |40990|Inf|Nor|2006-11-17|Cannot bind port or ip address for outgoing UDP so| |41006|Inf|Enh|2006-11-20
[jira] [Comment Edited] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917300#comment-13917300
]
Ralph Goers edited comment on LOG4J2-555 at 3/2/14 6:39 AM:
AbstractLogger is correct. Applications that invoke its methods will work
correctly. The problem here is that all the calls from a custom logger should
use the log(final Marker marker, final String fqcn, final Level level, final
Message data, final Throwable t) method of AbstractLoggerWrapper and provide
the fqcn.
I should add that at one point AbstractLogger had code similar to what you are
suggesting. It generally did not work because in most cases the application is
not calling a method in the subclass but is directly calling a method in
AbstractLogger, thus the FQCN needs to be for AbstractLogger, not the subclass.
I should also add that when AbstractLogger was first written it only had a
single abstract log method. Last year all the other log methods were added to
allow callers more flexibility to log at a specific level. We should document
that those methods are for users and should never be used by a Logger
implementation.
was (Author: ralph.go...@dslextreme.com):
AbstractLogger is correct. Applications that invoke its methods will work
correctly. The problem here is that all the calls from a custom logger should
use the log(final Marker marker, final String fqcn, final Level level, final
Message data, final Throwable t) method of AbstractLoggerWrapper and provide
the fqcn.
I should add that at one point AbstractLogger had code similar to what you are
suggesting. It generally did not work because in most cases the application is
not calling a method in the subclass but is directly calling a method in
AbstractLogger, thus the FQCN needs to be for AbstractLogger, not the subclass.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
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] [Comment Edited] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917300#comment-13917300
]
Ralph Goers edited comment on LOG4J2-555 at 3/2/14 6:33 AM:
AbstractLogger is correct. Applications that invoke its methods will work
correctly. The problem here is that all the calls from a custom logger should
use the log(final Marker marker, final String fqcn, final Level level, final
Message data, final Throwable t) method of AbstractLoggerWrapper and provide
the fqcn.
I should add that at one point AbstractLogger had code similar to what you are
suggesting. It generally did not work because in most cases the application is
not calling a method in the subclass but is directly calling a method in
AbstractLogger, thus the FQCN needs to be for AbstractLogger, not the subclass.
was (Author: ralph.go...@dslextreme.com):
AbstractLogger is correct. Applications that invoke its methods will work
correctly. The problem here is that all the calls from a custom logger should
use the log(final Marker marker, final String fqcn, final Level level, final
Message data, final Throwable t) method of AbstractLoggerWrapper and provide
the fqcn.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
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-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
[
https://issues.apache.org/jira/browse/LOG4J2-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917300#comment-13917300
]
Ralph Goers commented on LOG4J2-555:
AbstractLogger is correct. Applications that invoke its methods will work
correctly. The problem here is that all the calls from a custom logger should
use the log(final Marker marker, final String fqcn, final Level level, final
Message data, final Throwable t) method of AbstractLoggerWrapper and provide
the fqcn.
> Location-based functionality broken in AbstractLoggerWrapper subclasses
> ---
>
> Key: LOG4J2-555
> URL: https://issues.apache.org/jira/browse/LOG4J2-555
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.0-rc2
>
>
> *How to reproduce*
> * Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
> one with the tool attached to LOG4J2-519)
> * In the custom logger provide a public method that invokes the {{log(Level,
> String)}} method
> * Configure a pattern layout that uses location, like %C for the logger FQCN
> * From a sample app, call the public method on your custom logger.
> * The output will show the class name of the custom logger instead of the
> class name of the calling class in the sample application.
> *Cause*
> {{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
> {{AbstractLogger.class.getName()}}. Then, in
> {{Log4jLogEvent#calcLocation()}}, when walking over the stack trace elements,
> the element _following_ the FQCN is returned. So only loggers that directly
> subclass from {{AbstractLogger}} will work correctly. Loggers that inherit
> from {{AbstractLoggerWrapper}} are two levels removed from {{AbstractLogger}}
> and the {{calcLocation()}} method will not work correctly.
> *Solution*
> I think {{AbstractLogger}}'s FQCN field should be made non-static, and
> initialized to {{getClass().getName()}} in the constructor of
> {{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
> return the {{StackElement}} whose class name matches the FQCN, instead of the
> next element. Location-based functionality should then work for arbitrarily
> deep subclass hierarchies of AbstractLogger.
--
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] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma edited comment on LOG4J2-519 at 3/2/14 6:26 AM:
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
(depending on how many threads you use) because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
was (Author: rem...@yahoo.com):
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma edited comment on LOG4J2-519 at 3/2/14 6:25 AM:
vibin, thanks a lot for testing this!
The quick fix may be to use %c (lowercase) in your pattern layout instead of %C
(upper case). This will use the logger _name_ instead of its class and as a
side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
was (Author: rem...@yahoo.com):
vibin, the quick fix may be to use %c (lowercase) in your pattern layout
instead of %C (upper case). This will use the logger _name_ instead of its
class and as a side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917298#comment-13917298
]
Remko Popma commented on LOG4J2-519:
vibin, the quick fix may be to use %c (lowercase) in your pattern layout
instead of %C (upper case). This will use the logger _name_ instead of its
class and as a side-effect will be about [ten times
faster|http://logging.apache.org/log4j/2.x/manual/async.html#Throughput_of_Logging_With_Location_includeLocationtrue]
because it doesn't use reflection.
Ralph, this looks like a bug:
it basically means that any location-based logic is broken for loggers that
subclass AbstractLoggerWrapper. I've raised LOG4J2-555 for this.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to s
[jira] [Created] (LOG4J2-555) Location-based functionality broken in AbstractLoggerWrapper subclasses
Remko Popma created LOG4J2-555:
--
Summary: Location-based functionality broken in
AbstractLoggerWrapper subclasses
Key: LOG4J2-555
URL: https://issues.apache.org/jira/browse/LOG4J2-555
Project: Log4j 2
Issue Type: Bug
Components: API, Core
Affects Versions: 2.0-rc1
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.0-rc2
*How to reproduce*
* Create a custom logger that extends {{AbstractLoggerWrapper}} (or generate
one with the tool attached to LOG4J2-519)
* In the custom logger provide a public method that invokes the {{log(Level,
String)}} method
* Configure a pattern layout that uses location, like %C for the logger FQCN
* From a sample app, call the public method on your custom logger.
* The output will show the class name of the custom logger instead of the class
name of the calling class in the sample application.
*Cause*
{{AbstractLogger}}'s FQCN field is {{static final}} and initialized to
{{AbstractLogger.class.getName()}}. Then, in {{Log4jLogEvent#calcLocation()}},
when walking over the stack trace elements, the element _following_ the FQCN is
returned. So only loggers that directly subclass from {{AbstractLogger}} will
work correctly. Loggers that inherit from {{AbstractLoggerWrapper}} are two
levels removed from {{AbstractLogger}} and the {{calcLocation()}} method will
not work correctly.
*Solution*
I think {{AbstractLogger}}'s FQCN field should be made non-static, and
initialized to {{getClass().getName()}} in the constructor of
{{AbstractLogger}}. {{Log4jLogEvent#calcLocation()}} can then be modified to
return the {{StackElement}} whose class name matches the FQCN, instead of the
next element. Location-based functionality should then work for arbitrarily
deep subclass hierarchies of AbstractLogger.
--
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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917275#comment-13917275 ] Matt Sicker commented on LOG4J2-547: Yeah, I chose PrintStream originally because you could just wrap it in a PrintWriter. Using java.io.PrintWriter as the FQCN doesn't seem too hacky considering that's the class being used for method calls. I wasn't sure that would work properly, though, as it the call stack then depends on which method in PrintWriter you call (which can differ based on the JDK in use at the time and the internal class structure). If you've got more than one JDK installed, it would be good to test out any fix in as many different environments as possible (e.g., JDK 6, 7, 8, and even a different JVM if possible like JRockit). > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > Add_caller_info_tests.patch, log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917268#comment-13917268 ] Bruce Brouwer commented on LOG4J2-547: -- Thanks, I'll use those unit tests. Here's what I was thinking and a quick spike proved it works. If I pass the FQCN to the LoggerWriter and make the FQCN=java.io.PrintWriter, I get the correct call information. I don't have to decorate any classes. But is that too hacky to give PrintWriter as the FQCN to the LoggerWriter? Also, I didn't realize initially that you were using PrintStream, not PrintWriter. In some ways, I prefer your idea of using PrintWriter. It is easier to turn a PrintStream into a PrintWriter than the other way around. Or do you think there is value in keeping both? > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > Add_caller_info_tests.patch, log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Comment Edited] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917268#comment-13917268 ] Bruce Brouwer edited comment on LOG4J2-547 at 3/2/14 2:15 AM: -- Thanks, I'll use those unit tests. Here's what I was thinking and a quick spike proved it works. If I pass the FQCN to the LoggerWriter and make the FQCN=java.io.PrintWriter, I get the correct call information. I don't have to decorate any classes. But is that too hacky to give PrintWriter as the FQCN to the LoggerWriter? Also, I didn't realize initially that you were using PrintStream, not PrintWriter. In some ways, I prefer your idea of using PrintStream. It is easier to turn a PrintStream into a PrintWriter than the other way around. Or do you think there is value in keeping both? was (Author: bruce.brouwer): Thanks, I'll use those unit tests. Here's what I was thinking and a quick spike proved it works. If I pass the FQCN to the LoggerWriter and make the FQCN=java.io.PrintWriter, I get the correct call information. I don't have to decorate any classes. But is that too hacky to give PrintWriter as the FQCN to the LoggerWriter? Also, I didn't realize initially that you were using PrintStream, not PrintWriter. In some ways, I prefer your idea of using PrintWriter. It is easier to turn a PrintStream into a PrintWriter than the other way around. Or do you think there is value in keeping both? > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > Add_caller_info_tests.patch, log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Updated] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-547: --- Attachment: Add_caller_info_tests.patch Here's a unit test to demonstrate the calling class and calling method information. Originally, I was going to split the two test methods into four, but really, they're both testing the same functionality, so it made sense to combine them. As you can see, running the tests on the current trunk will fail, but only once it gets to verifying the contents of the log message created via the print writer. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > Add_caller_info_tests.patch, log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Reopened] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reopened LOG4J2-547: Needs correct caller information. I'll submit a patch for the unit tests in just a moment. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917247#comment-13917247 ] Bruce Brouwer commented on LOG4J2-547: -- I wasn't picking up on that. I'll take a look at it. I think I know now what you're saying the problem is. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-547) Update LoggerStream API
[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917245#comment-13917245
]
Matt Sicker commented on LOG4J2-547:
Just as I suspected. By not decorating PrintWriter, now the calling information
says that {{java.io.Writer}} is the calling class.
> Update LoggerStream API
> ---
>
> Key: LOG4J2-547
> URL: https://issues.apache.org/jira/browse/LOG4J2-547
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Matt Sicker
>Assignee: Ralph Goers
> Fix For: 2.0
>
> Attachments: 0001-PrintStream-API-update.patch,
> log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a
> little while ago. The main thing I'd like to do is extract an interface from
> it, rename the default implementation to SimpleLoggerStream (part of the
> SimpleLogger stuff), and allow log4j implementations to specify a different
> implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream
> methods to be. Right now, it's in Logger, but really, it could be in
> LoggerContext instead. I don't think I should be required to get a Logger
> just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This
> would be so much easier to design!
--
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] [Assigned] (LOG4J2-435) Support limiting number of log files based on date pattern
[ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-435: -- Assignee: Ralph Goers > Support limiting number of log files based on date pattern > -- > > Key: LOG4J2-435 > URL: https://issues.apache.org/jira/browse/LOG4J2-435 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Arkin Yetis >Assignee: Ralph Goers > > DefaultRolloverStrategy max attribute only applies if you have a %i in the > file pattern. This request is to enhance DefaultRolloverStrategy or another > appropriate component to allow a max number of files limit to apply across > days/months/years when a filePattern includes a date pattern. -- 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] [Assigned] (LOG4J2-494) Support composite configurations
[ https://issues.apache.org/jira/browse/LOG4J2-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-494: -- Assignee: Ralph Goers > Support composite configurations > > > Key: LOG4J2-494 > URL: https://issues.apache.org/jira/browse/LOG4J2-494 > Project: Log4j 2 > Issue Type: New Feature > Components: Configurators >Affects Versions: 2.0-beta9 >Reporter: Ralph Goers >Assignee: Ralph Goers > > Support was added to XMLConfiguration to allow XIncludes in the XML files. > While this can be useful it does not allow for the use case where someone > wants a default configuration and then a custom configuration to be merged > with it. > I am proposing creating a CompositeConfiguration class that accepts a comma > separated list of configuration files. It would then use the Configuration > factories to create the appropriate Configuration classes for each of the > underlying files. It would then merge the Node hierarchies created by each > into a single tree and then finally construct the actual configuration > Objects from that tree. > There are a few issues with this - for example each configuration can specify > debug and verbose attributes, duplicate property settings, handling duplicate > Appender names, etc. Most of these should be fairly easy to resolve. -- 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
Re: What will the GA version number be?
Just a quick follow up to this: 2.0 works perfectly fine in OSGi. Even the version number 2 would work. Either one gets automatically expanded to 2.0.0, or they're interpreted as the same version number regardless. On 4 February 2014 17:48, Matt Sicker wrote: > I prefer the aesthetics of 2.0, but prefer 2.0.0 due to semver. Then > again, as long as we make the OSGi version 2.0.0, we're good. That's > configurable in the OSGi pom.xml files. > > > On 4 February 2014 05:02, Ralph Goers wrote: > >> I haven't really heard anything to make me change my mind. 2.0. >> >> Sent from my iPad >> >> On Feb 3, 2014, at 11:44 PM, Nick Williams >> wrote: >> >> Maybe he'll respond again tonight and let us know if he's set on 2.0 or >> fine with 2.0.0. :-) >> >> N >> >> On Feb 4, 2014, at 1:42 AM, Gary Gregory wrote: >> >> I'm happy to let Ralph pick, either way is fine with me. >> >> Gary >> >> >> On Tue, Feb 4, 2014 at 2:27 AM, Nick Williams < >> nicho...@nicholaswilliams.net> wrote: >> >>> Matt and Christian did, however, point out semver. There's something to >>> be said about following a community practice, and use of x.y.z far >>> outweighs use of x.y in OSS. >>> >>> N >>> >>> On Feb 4, 2014, at 1:21 AM, Gary Gregory wrote: >>> >>> Nick, >>> >>> I do not think you can go wrong by writing 2.0 in the book. I'm OK with >>> 2.0 and 2.0.0 even though 2.0.0 feels redundant. Like someone else posted I >>> find the .FINAL and -RELEASE and whatnot ludicrous. >>> >>> Gary >>> >>> >>> On Tue, Feb 4, 2014 at 2:14 AM, Nick Williams < >>> nicho...@nicholaswilliams.net> wrote: >>> Well well well. I'm sensing a lot of disagreement. Too bad my book goes to the printers Wednesday. I have a feeling no matter what I put in it there's a good chance it'll change. :-P Any way we can come to a consensus in the next 6-8 hours or so (by 9 a.m. CST)? N On Feb 3, 2014, at 3:46 PM, Matt Sicker wrote: Plus, if we're really keen on OSGi support, note that OSGi assumes version numbers follow the semantic versioning scheme. Producers use an API like [1.1, 1.2), whereas consumers use an API like [1.1, 2.0). Yes, those are half-open intervals, and yes, that is the official notation. :) On 3 February 2014 15:41, Christian Grobmeier wrote: > On 3 Feb 2014, at 22:14, Matt Sicker wrote: > > > I like 2.0.0 because semver.org etc., although as long as it's not > a dumb > > version number like GA or RELEASE or Final, I'm happy with it. > > Sticking with semver might be a good idea. Its a language many > understand > and we should try to stick with that lanugage as well. > > > > > > > On 3 February 2014 07:07, Gary Gregory > wrote: > > > >> Keep it simple: 2.0. > >> > >> Gary > >> > >> > >> Original message > >> From: Christian Grobmeier > >> Date:02/03/2014 05:12 (GMT-05:00) > >> To: Log4J Developers List > >> Subject: Re: What will the GA version number be? > >> > >> Also 2.0 or 2.0.0 for me > >> > >> On 3 Feb 2014, at 7:41, Ralph Goers wrote: > >> > >>> I had thought it would be 2.0. > >>> > >>> Sent from my iPad > >>> > On Feb 2, 2014, at 8:59 PM, Nick Williams > wrote: > > I'm finalizing the logging chapter of my book to send to the > printers > Wednesday (I'm so glad I got to correct it to say Level was > extendable!), and I need to know what the Maven artifact GA > version > number will be. I print the new Maven artifacts used in each > chapter > on the first page of the chapter as a guide to the user. Log4j is > the > only library I'm using that isn't yet GA. I want to be sure the > version numbers I'm printing are correct. > > Here are the options that I can think of for the GA release: > > 2.0 > 2.0-GA > 2.0.GA > 2.0.Final > 2.0.RELEASE > 2.0.0 > 2.0.0-GA > 2.0.0.GA > 2.0.0.Final > 2.0.0.RELEASE > > So, which is it going to be? I assume that eventually we're going > to > have a 2.0.1, 2.0.2, etc., so it would seem to me that, whatever > GA > is, it should start with 2.0.0. Doesn't seem to make a lot of > sense > to go from 2.0 to 2.0.1. However, all of our beta releases have > been > 2.0-Betan. > > Thoughts? > > Nick > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: > log4j-dev-h...@logging.apache.org > > >>> > >>> > - > >>> T
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917192#comment-13917192
]
vibin commented on LOG4J2-519:
--
Is there a quick solution to fix this issue ..? i tried setting FQCN in the
wrapper calss , did not work..
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom levels to support and their {{intLevel}} relative
> strength
> * whether to extend {{Logger}} (and keep the existing built-in methods) or
> have only methods for the custom log levels
> and the tool generates the source code for the wrapper class th
[jira] [Closed] (LOG4J2-439) Create a LogEventPatternConverter to escape newlines and HTML special characters
[
https://issues.apache.org/jira/browse/LOG4J2-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Brouwer closed LOG4J2-439.
It works just as I expected. Thanks.
> Create a LogEventPatternConverter to escape newlines and HTML special
> characters
>
>
> Key: LOG4J2-439
> URL: https://issues.apache.org/jira/browse/LOG4J2-439
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.0-beta9
>Reporter: Bruce Brouwer
>Assignee: Ralph Goers
> Fix For: 2.0-rc2
>
> Attachments: EncodingPatternConverter.patch
>
>
> To prevent log forging and HTML based attacks from viewing logs in a browser,
> we could add a LogEventPatternConverter that escapes newlines and HTML
> special characters. [ESAPI has a method to do
> this|http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc7/apidocs/org/owasp/esapi/Logger.html],
> but it doesn't have any of the nice API features that Log4j 2 has.
> I was able to create a LogEventPatternConverter to do this. Note, this is
> only a proof of concept. I didn't try to exhaustively list all the special
> characters that might need to be replaced. I also didn't provide any
> configuration so we could choose to not escape HTML, for example.
> With this configuration:
> {code:xml}
>
> {code}
> And logging this message:
> {code}
> LOG.warn("hi\n & there");
> {code}
> Would result in this being logged:
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi\n & there
> {code}
> instead of this (which shows the potential for log forging):
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi
> & there
> {code}
> This is roughly the code I used:
> {code}
> @Plugin(name = "escape", category = "Converter")
> @ConverterKeys({ "escape" })
> public final class EscapingReplacementConverter extends
> LogEventPatternConverter {
> private final List formatters;
> private EscapingReplacementConverter(final List
> formatters) {
> super("escape", "escape");
> this.formatters = formatters;
> }
> public static EscapingReplacementConverter newInstance(final
> Configuration config,
>final String[]
> options) {
> if (options.length != 1) {
> LOGGER.error("Incorrect number of options on escape. Expected 1,
> received "
> + options.length);
> return null;
> }
> if (options[0] == null) {
> LOGGER.error("No pattern supplied on escape");
> return null;
> }
> final PatternParser parser =
> PatternLayout.createPatternParser(config);
> final List formatters = parser.parse(options[0]);
> return new EscapingReplacementConverter(formatters);
> }
> @Override
> public void format(final LogEvent event, final StringBuilder toAppendTo) {
> final StringBuilder buf = new StringBuilder();
> for (final PatternFormatter formatter : formatters) {
> formatter.format(event, buf);
> }
> toAppendTo.append(buf.toString()
> .replaceAll("\\r", "r")
> .replaceAll("\\n", "n")
> .replaceAll("&", "&")
> .replaceAll("<", "<")
> .replaceAll(">", ">"));
> }
> }
> {code}
> If this sounds good, I would like to hear feedback and ideas on how to make
> this better. I will then contribute this to the project. Do you think this
> could this get in 2.0?
--
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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917184#comment-13917184 ] Bruce Brouwer commented on LOG4J2-547: -- Also, you should be able to delete LoggerStream and LoggerStreamTest > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-510) How to close inactive log files
[ https://issues.apache.org/jira/browse/LOG4J2-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917183#comment-13917183 ] Ralph Goers commented on LOG4J2-510: Are you creating the files using the RoutingAppender? We need a few more details to understand exactly what the issue is. Can you provide a sample configuration file? > How to close inactive log files > --- > > Key: LOG4J2-510 > URL: https://issues.apache.org/jira/browse/LOG4J2-510 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta9 > Environment: linux >Reporter: Eric > Labels: performance > Fix For: 2.0-beta9 > > > Hi There, > in log4j2 when the App start logging it create and open a file to log into > and that file stay open as long as the App is running. > in my case log4j2 create and open too many files base on ThreadContext and > the OS (linux) will complaint that too many files are open and my App will > crash and stop responding. > My question is: > 1 - how do you close those files with log4j2 if they are inactive for a > period of time. > 2 - How do you have access to the log4j2 handle that open those files. > 3 - How do you tell log4j2 to open a file just for a period of time. > Thanks > Eric -- 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-508) Add new Levels: NOTICE, DIAG, VERBOSE.
[ https://issues.apache.org/jira/browse/LOG4J2-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917182#comment-13917182 ] Bruce Brouwer commented on LOG4J2-508: -- My vote would be to not add this to the core log4j api. There are some other issues (like LOG4J2-519) that talk about making custom logger interfaces which might handle this use case. > Add new Levels: NOTICE, DIAG, VERBOSE. > -- > > Key: LOG4J2-508 > URL: https://issues.apache.org/jira/browse/LOG4J2-508 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-beta9 > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) > Maven home: C:\Java\apache-maven-3.1.1\bin\.. > Java version: 1.7.0_51, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_51\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory > Fix For: 2.0-rc2 > > > Discussion thread: > https://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201401.mbox/ajax/%3CBD972E2F-C818-47BD-BB9E-168D52D5D980%40nicholaswilliams.net%3E > The levels: > - FATAL - Hopefully, almost never logged because the system is crashing. > - ERROR - Something affecting the usability of the system occurred. > - WARN - Something not nice, but probably recoverable occurred. May lead to > errors later. > - NOTICE - An event for normal, but significant, conditions. > - INFO - Something of general interest, but not necessarily significant. > - DIAG or DIAGNOSTIC - Events that can be used by operations or users to > diagnose problems in the system. > - DEBUG - Used by developers for internal debugging. > - VERBOSE - Used to log minute details of the system. As its dictionary > definition implies this is extremely chatty. > - TRACE - Adds tracing of method entry and exit, possibly object creation and > initialization. > From (with the NOTICE level added) > https://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201401.mbox/browser -- 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-510) How to close inactive log files
[ https://issues.apache.org/jira/browse/LOG4J2-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917181#comment-13917181 ] Bruce Brouwer commented on LOG4J2-510: -- What does your configuration look like that log4j2 is creating many open files? The general use case that I'm aware of opens a file and keeps it open for the life of the app. If you simply want a way to configure log4j to close a log file after some period of inactivity, this should be changed to an enhancement request. In that case, I would suggest delaying this until after 2.0 GA > How to close inactive log files > --- > > Key: LOG4J2-510 > URL: https://issues.apache.org/jira/browse/LOG4J2-510 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0-beta9 > Environment: linux >Reporter: Eric > Labels: performance > Fix For: 2.0-beta9 > > > Hi There, > in log4j2 when the App start logging it create and open a file to log into > and that file stay open as long as the App is running. > in my case log4j2 create and open too many files base on ThreadContext and > the OS (linux) will complaint that too many files are open and my App will > crash and stop responding. > My question is: > 1 - how do you close those files with log4j2 if they are inactive for a > period of time. > 2 - How do you have access to the log4j2 handle that open those files. > 3 - How do you tell log4j2 to open a file just for a period of time. > Thanks > Eric -- 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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917180#comment-13917180 ] Bruce Brouwer commented on LOG4J2-547: -- One thing I noticed I missed. We might want to synchronize on buf in the close() method. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Assigned] (LOG4J2-535) Rolled log files end up in the wrong directory
[
https://issues.apache.org/jira/browse/LOG4J2-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-535:
--
Assignee: Ralph Goers
> Rolled log files end up in the wrong directory
> --
>
> Key: LOG4J2-535
> URL: https://issues.apache.org/jira/browse/LOG4J2-535
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-rc1
> Environment: Ubuntu 12.04 and 13.04, java version "1.7.0_51"
>Reporter: Remko Popma
>Assignee: Ralph Goers
>
> Follow-up for issue LOG4J2-531: the main issue (rolled over archives were
> overwritten) was resolved but the solution brought to light another issue
> that is tracked here:
> The distribution of the log files into the folders is odd and it feels like
> there might be a flaw in the timestamp logic in there somewhere still.
> Test program to reproduce the issue:
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
> public class LogTest {
> private static final Logger logger = LogManager.getLogger("TestLogger");
> public static void main(String[] args) throws Exception {
> for (long i=0; ; i+=1) {
> logger.debug("Sequence: " + i);
> Thread.sleep(250);
> }
> }
> }
> {code}
> Sample configuration for LOG4J2-531:
> {code}
>
>
>
> filePattern="logs/test/$${date:MMddHHmm}/TEST-%d{MMddHHmm}-%i.log.gz">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I kicked off the test run at {{14:29:11}} using my example setup from the
> first post above more or less as is - but with a more sensible {{max=99}}.
> The initial folder created was {{201402101429}} and contained 27 numbered
> files prefixed {{TEST-201402101429-}}. Numbers 1-12 contained 16 log lines
> each with timestamps {{14:29:11,667}} to {{14:29:59,649}}, number 13 a single
> log line with timestamp {{14:29:59,899}}, and numbers 14-27 again contain 16
> lines each with timestamps {{14:30:00,164}} to {{14:30:56,155}}.
> The second folder created was {{201402101430}} and contained 15 numbered
> files. The first file contained 15 log lines with timestamps {{14:30:56,405}}
> to {{14:30:59,919}}. The subsequent files contained 16 log lines each with
> timestamps {{14:31:00,170}} to {{14:31:56,123}}.
> The third folder created was {{201402101431}}. The first file contained 15
> log lines with timestamps {{14:31:56,373}} to {{14:31:59,886}}. The
> subsequent files contained 16 log lines each with timestamps from
> {{14:32:00,136}} onwards.
> So in summary after the first minute the majority of log lines from minute X
> end up in the folder for minute X-1. The exception are the last file of lines
> which end up in the correct folder.
>
> This happens with longer rollover periods as well:
>
> Sample configuration based on that for LOG4J2-531, adjusted to roll every
> hour and every 64kb (i.e. expect similar number of files per folder):
> {code:xml}
>
>
>
> filePattern="logs/test/$${date:MMddHH}/TEST-%d{MMddHH}-%i.log.gz">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Running this overnight gave a similar pattern, e.g. the folder for
> {{2014021100}} contains one file with timestamps {{00:59:42,836}} to
> {{00:59:59,851}}, and then 15 others covering timestamps {{01:00:00,101}} to
> {{01:59:24,196}}. Only the last file's worth for each hour (the one rotated
> based on time) is in the correct folder, and the rest (rotated based on size)
> are in the previous hour's folder.
--
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] [Resolved] (LOG4J2-303) No WriterAppender functionality in Log4j2
[ https://issues.apache.org/jira/browse/LOG4J2-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-303. Resolution: Not A Problem Closing due to a lack of a response from the reporter. > No WriterAppender functionality in Log4j2 > - > > Key: LOG4J2-303 > URL: https://issues.apache.org/jira/browse/LOG4J2-303 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Affects Versions: 2.0-beta7 >Reporter: Tom Smith > > I have an app that uses a log4J 1.2 style WriterAppender to write to a JavaFX > window that so it can display the output in various ways (console, table > etc). I can't get the same functionality with Log4j2-- Is this a deliberate > oversight because of the xml configuration system? -- 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] [Closed] (LOG4J2-303) No WriterAppender functionality in Log4j2
[ https://issues.apache.org/jira/browse/LOG4J2-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-303. -- > No WriterAppender functionality in Log4j2 > - > > Key: LOG4J2-303 > URL: https://issues.apache.org/jira/browse/LOG4J2-303 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Affects Versions: 2.0-beta7 >Reporter: Tom Smith > > I have an app that uses a log4J 1.2 style WriterAppender to write to a JavaFX > window that so it can display the output in various ways (console, table > etc). I can't get the same functionality with Log4j2-- Is this a deliberate > oversight because of the xml configuration system? -- 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] [Resolved] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-547. Resolution: Fixed Bruce's patch was applied in revision 1573212. Please verify that this addresses the problem and works and then close. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Resolved] (LOG4J2-439) Create a LogEventPatternConverter to escape newlines and HTML special characters
[
https://issues.apache.org/jira/browse/LOG4J2-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-439.
Resolution: Fixed
Fix Version/s: 2.0-rc2
Patch applied in revision 1573211. Please verify and close.
> Create a LogEventPatternConverter to escape newlines and HTML special
> characters
>
>
> Key: LOG4J2-439
> URL: https://issues.apache.org/jira/browse/LOG4J2-439
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.0-beta9
>Reporter: Bruce Brouwer
>Assignee: Ralph Goers
> Fix For: 2.0-rc2
>
> Attachments: EncodingPatternConverter.patch
>
>
> To prevent log forging and HTML based attacks from viewing logs in a browser,
> we could add a LogEventPatternConverter that escapes newlines and HTML
> special characters. [ESAPI has a method to do
> this|http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc7/apidocs/org/owasp/esapi/Logger.html],
> but it doesn't have any of the nice API features that Log4j 2 has.
> I was able to create a LogEventPatternConverter to do this. Note, this is
> only a proof of concept. I didn't try to exhaustively list all the special
> characters that might need to be replaced. I also didn't provide any
> configuration so we could choose to not escape HTML, for example.
> With this configuration:
> {code:xml}
>
> {code}
> And logging this message:
> {code}
> LOG.warn("hi\n & there");
> {code}
> Would result in this being logged:
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi\n & there
> {code}
> instead of this (which shows the potential for log forging):
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi
> & there
> {code}
> This is roughly the code I used:
> {code}
> @Plugin(name = "escape", category = "Converter")
> @ConverterKeys({ "escape" })
> public final class EscapingReplacementConverter extends
> LogEventPatternConverter {
> private final List formatters;
> private EscapingReplacementConverter(final List
> formatters) {
> super("escape", "escape");
> this.formatters = formatters;
> }
> public static EscapingReplacementConverter newInstance(final
> Configuration config,
>final String[]
> options) {
> if (options.length != 1) {
> LOGGER.error("Incorrect number of options on escape. Expected 1,
> received "
> + options.length);
> return null;
> }
> if (options[0] == null) {
> LOGGER.error("No pattern supplied on escape");
> return null;
> }
> final PatternParser parser =
> PatternLayout.createPatternParser(config);
> final List formatters = parser.parse(options[0]);
> return new EscapingReplacementConverter(formatters);
> }
> @Override
> public void format(final LogEvent event, final StringBuilder toAppendTo) {
> final StringBuilder buf = new StringBuilder();
> for (final PatternFormatter formatter : formatters) {
> formatter.format(event, buf);
> }
> toAppendTo.append(buf.toString()
> .replaceAll("\\r", "r")
> .replaceAll("\\n", "n")
> .replaceAll("&", "&")
> .replaceAll("<", "<")
> .replaceAll(">", ">"));
> }
> }
> {code}
> If this sounds good, I would like to hear feedback and ideas on how to make
> this better. I will then contribute this to the project. Do you think this
> could this get in 2.0?
--
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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917167#comment-13917167 ] Matt Sicker commented on LOG4J2-547: I like this print writer patch better, too. The only reason my patch started getting complicated was due to the call stack getting weird if you didn't make a decorate class for PrintStream or similar. Then it became next to impossible to figure out the calling class to construct it properly. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917166#comment-13917166 ] Ralph Goers commented on LOG4J2-547: I'm going to look at it a bit more after I apply the patch, but at first glance I like this patch a lot more. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Assigned] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-547: -- Assignee: Ralph Goers > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Comment Edited] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917159#comment-13917159 ] Bruce Brouwer edited comment on LOG4J2-547 at 3/1/14 7:04 PM: -- In looking at LoggerStream, I can see how it could help me when shelling out to commands when all I want to do is log the output of that shelled command. There is some non-trivial stuff that LoggerStream is doing, so I don't want to get rid of that concept. But I agree that as it stands, the most helpful part of LoggerStream is actually the HelperStream. I'm including a patch that gets rid of LoggerStream and instead returns a plain old PrintWriter. This involved making a LoggerWriter which does basically what HelperStream did before. I don't see a whole lot of value adding this to the LoggerContext. In the end it needs an AbstractLogger anyway, so why not get it from the AbstractLogger. Oh, and I called the method .printWriter(...) instead of .getStream(...). First, the old .getStream didn't even return an OutputStream, it returned something that extended PrintWriter. And also, by removing the .get part, users might not expect to get the exact same PrintWriter instance each time they call it. In this case, I don't think I would want to get the same instance each time. was (Author: bruce.brouwer): In looking at LoggerStream, I can see how it could help me when shelling out to commands when all I want to do is log the output of that shelled command. There is some non-trivial stuff that LoggerStream is doing, so I don't want to get rid of that concept. But I agree that as it stands, the most helpful part of LoggerStream is actually the HelperStream. I'm including a patch that gets rid of LoggerStream and instead returns a plain old PrintWriter. This involved making a LoggerWriter which does basically what HelperStream did before. I don't see a whole lot of value adding this to the LoggerContext. In the end it needs an AbstractLogger anyway, so why not get it from the AbstractLogger. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Updated] (LOG4J2-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Brouwer updated LOG4J2-547: - Attachment: log4j2-loggerStream.patch > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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-547) Update LoggerStream API
[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917159#comment-13917159 ] Bruce Brouwer commented on LOG4J2-547: -- In looking at LoggerStream, I can see how it could help me when shelling out to commands when all I want to do is log the output of that shelled command. There is some non-trivial stuff that LoggerStream is doing, so I don't want to get rid of that concept. But I agree that as it stands, the most helpful part of LoggerStream is actually the HelperStream. I'm including a patch that gets rid of LoggerStream and instead returns a plain old PrintWriter. This involved making a LoggerWriter which does basically what HelperStream did before. I don't see a whole lot of value adding this to the LoggerContext. In the end it needs an AbstractLogger anyway, so why not get it from the AbstractLogger. > Update LoggerStream API > --- > > Key: LOG4J2-547 > URL: https://issues.apache.org/jira/browse/LOG4J2-547 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Fix For: 2.0 > > Attachments: 0001-PrintStream-API-update.patch, > log4j2-loggerStream.patch > > > I've got some ideas on how to improve the LoggerStream idea that I added a > little while ago. The main thing I'd like to do is extract an interface from > it, rename the default implementation to SimpleLoggerStream (part of the > SimpleLogger stuff), and allow log4j implementations to specify a different > implementation if desired. > In doing this, I'm not sure where specifically I'd prefer the getStream > methods to be. Right now, it's in Logger, but really, it could be in > LoggerContext instead. I don't think I should be required to get a Logger > just to get a LoggerStream. > Now if only the java.io package used interfaces instead of classes. This > would be so much easier to design! -- 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] [Updated] (LOG4J2-553) Migration from 1.x page lists incorrect classes
[ https://issues.apache.org/jira/browse/LOG4J2-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-553: --- Attachment: 0001-Fix-migration-documentation.patch Here's a patch. > Migration from 1.x page lists incorrect classes > --- > > Key: LOG4J2-553 > URL: https://issues.apache.org/jira/browse/LOG4J2-553 > Project: Log4j 2 > Issue Type: Bug > Components: Documentation >Reporter: Mike Calmus >Priority: Minor > Attachments: 0001-Fix-migration-documentation.patch > > > The "Migrating from Log4j 1.x" page > (http://logging.apache.org/log4j/2.x/manual/migration.html) says in step 3 > under "Using the Log4j 1.x bridge": > 3.They must not configure by calling the classes DomConfigurator or > PropertiesConfigurator > The classes lsited should be DOMConfigurator and PropertyConfigurator. -- 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] [Closed] (LOG4J2-490) Upgrade EasyMock to 3.2
[ https://issues.apache.org/jira/browse/LOG4J2-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-490. -- Forgot to close this. > Upgrade EasyMock to 3.2 > --- > > Key: LOG4J2-490 > URL: https://issues.apache.org/jira/browse/LOG4J2-490 > Project: Log4j 2 > Issue Type: Dependency upgrade > Components: Core >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker > Labels: EasyMock, Test > Attachments: 0001-Upgrade-EasyMock-to-3.2.patch > > Original Estimate: 10m > Remaining Estimate: 10m > > EasyMock 3.2 is out. Similar to Mockito, they now have annotations and a > JUnit runner for making mocks a lot easier. -- 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] [Closed] (LOG4J2-489) Should JPADatabaseManager being using so many transactions?
[ https://issues.apache.org/jira/browse/LOG4J2-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-489. -- > Should JPADatabaseManager being using so many transactions? > --- > > Key: LOG4J2-489 > URL: https://issues.apache.org/jira/browse/LOG4J2-489 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.0 > Environment: JPA appender >Reporter: Matt Sicker >Assignee: Nick Williams >Priority: Minor > Labels: Appender, JPA, Performance, Transaction > Fix For: 2.0-rc1 > > > Even when the appender is buffered, every log event is still committed each > time. In JDBCAppender, when it's buffered, log events aren't inserted into > the database until the buffer is full. > I tried to address this while I was working on another patch, but there's no > good way to generate an EntityTransaction without the EntityManager, and > that's recreated each time writeInternal() is called. -- 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] [Closed] (LOG4J2-499) LogEvent classes don't override equals() and hashCode()
[ https://issues.apache.org/jira/browse/LOG4J2-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-499. -- All good now! > LogEvent classes don't override equals() and hashCode() > --- > > Key: LOG4J2-499 > URL: https://issues.apache.org/jira/browse/LOG4J2-499 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Affects Versions: 2.0-rc1 >Reporter: Matt Sicker >Assignee: Ralph Goers >Priority: Minor > Labels: newbie, serialization, test > Fix For: 2.0-rc2 > > > Despite being serialisable, LogEvent implementations don't override .equals() > and .hashCode(). This would be rather useful for verifying serialisation > behaviour in, for instance, LogEventTest. -- 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] [Assigned] (LOG4J2-439) Create a LogEventPatternConverter to escape newlines and HTML special characters
[
https://issues.apache.org/jira/browse/LOG4J2-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-439:
--
Assignee: Ralph Goers
> Create a LogEventPatternConverter to escape newlines and HTML special
> characters
>
>
> Key: LOG4J2-439
> URL: https://issues.apache.org/jira/browse/LOG4J2-439
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.0-beta9
>Reporter: Bruce Brouwer
>Assignee: Ralph Goers
> Attachments: EncodingPatternConverter.patch
>
>
> To prevent log forging and HTML based attacks from viewing logs in a browser,
> we could add a LogEventPatternConverter that escapes newlines and HTML
> special characters. [ESAPI has a method to do
> this|http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc7/apidocs/org/owasp/esapi/Logger.html],
> but it doesn't have any of the nice API features that Log4j 2 has.
> I was able to create a LogEventPatternConverter to do this. Note, this is
> only a proof of concept. I didn't try to exhaustively list all the special
> characters that might need to be replaced. I also didn't provide any
> configuration so we could choose to not escape HTML, for example.
> With this configuration:
> {code:xml}
>
> {code}
> And logging this message:
> {code}
> LOG.warn("hi\n & there");
> {code}
> Would result in this being logged:
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi\n & there
> {code}
> instead of this (which shows the potential for log forging):
> {code}
> 2013-10-28 16:31:21,606 WARN [main] example.Test hi
> & there
> {code}
> This is roughly the code I used:
> {code}
> @Plugin(name = "escape", category = "Converter")
> @ConverterKeys({ "escape" })
> public final class EscapingReplacementConverter extends
> LogEventPatternConverter {
> private final List formatters;
> private EscapingReplacementConverter(final List
> formatters) {
> super("escape", "escape");
> this.formatters = formatters;
> }
> public static EscapingReplacementConverter newInstance(final
> Configuration config,
>final String[]
> options) {
> if (options.length != 1) {
> LOGGER.error("Incorrect number of options on escape. Expected 1,
> received "
> + options.length);
> return null;
> }
> if (options[0] == null) {
> LOGGER.error("No pattern supplied on escape");
> return null;
> }
> final PatternParser parser =
> PatternLayout.createPatternParser(config);
> final List formatters = parser.parse(options[0]);
> return new EscapingReplacementConverter(formatters);
> }
> @Override
> public void format(final LogEvent event, final StringBuilder toAppendTo) {
> final StringBuilder buf = new StringBuilder();
> for (final PatternFormatter formatter : formatters) {
> formatter.format(event, buf);
> }
> toAppendTo.append(buf.toString()
> .replaceAll("\\r", "r")
> .replaceAll("\\n", "n")
> .replaceAll("&", "&")
> .replaceAll("<", "<")
> .replaceAll(">", ">"));
> }
> }
> {code}
> If this sounds good, I would like to hear feedback and ideas on how to make
> this better. I will then contribute this to the project. Do you think this
> could this get in 2.0?
--
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=13917149#comment-13917149 ] Ralph Goers commented on LOG4J2-440: Erico - is this still a problem with 2.0-rc1? > 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] [Assigned] (LOG4J2-441) logger level configuration does not work correct
[
https://issues.apache.org/jira/browse/LOG4J2-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-441:
--
Assignee: Ralph Goers
> logger level configuration does not work correct
>
>
> Key: LOG4J2-441
> URL: https://issues.apache.org/jira/browse/LOG4J2-441
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Andreas Rytina
>Assignee: Ralph Goers
> Attachments: log4j2.xml.row1, log4j2.xml.row10, log4j2.xml.row11,
> log4j2.xml.row12, log4j2.xml.row13, log4j2.xml.row2, log4j2.xml.row3,
> log4j2.xml.row4, log4j2.xml.row5, log4j2.xml.row6, log4j2.xml.row7,
> log4j2.xml.row8, log4j2.xml.row9
>
>
> Configuring the loglevel in the logger does not work in combination with
> configuring the loglevel at the appender-refs. I analyzed this with the
> beta9. See the table which lists various loglevel configurations for the 3
> loggers. The column format for the table is:
> Column 1-6 are the logger with their level config (level@logger1,
> level@appender-ref)(level@logger2, level@appender-ref)(level@logger3,
> level@appender-ref)
> Column 7 is the actual output
> Column 8 is the expected Output
> For instance the first row of the table shows a logging result which I not
> expected in that way. You can take log4j2.xml.row1 to reproduce the first
> row. The first logger is named "com". The second logger is named
> "com.log4jtest" and the third logger is named "com.log4jtest.test". This
> looks like a bug in log4j 2.0:
> Logger1 considers the levels {info, debug, warning} but not the level trace.
> {color:red}What is the default level, if there is no level defined at the
> logger header and also not at the appender-ref?{color} Here it seems that the
> Logger1 has the level debug as default which is not clear for me. For me it
> would make sense if the default level is either OFF or ALL when there is no
> explicit level set. But either way there should be a clear rule for this. The
> other rows are showing similar inconsistent logging behaviour.
> |1|2|3|4|5|6|7|8|
> ||level 1 logger||level 1 appender-ref||level 2 logger||level 2
> appender-ref||level 3 logger ||level 3 appender-ref||actual output||expected
> output||
> |-|-|-|info|debug|debug|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger1: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|Logger3: info logger
> Logger2: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger|
> |-|-|-|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger|
> |-|-|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger|
> |fatal|fatal|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger|
> |info|info|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|
> |debug|debug|info|info| |debug|no output|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|
> |info|debug|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|
> |debug|info|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|
> |debug|trace|info|info|-|debug|no output|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger|
> |-|-|info|info|fatal|debug|no output|Logger2: info logger
> Logger2: warning logger|
> |-|-|info|info|trace|debug|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger1: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger
> Logger1: trace logger|Logger3: info logger
> Logger2: info logger
> Logger3: debug logger
> Logger2: warning logger|
> |-|-|-|info|trace|debug|Logger3: info logger
> Logger2: info logger
> Logger1: info logger
> Logger3: debug logger
> Logger1: debug logger
> Logger3: warning logger
> Logger2: warning logger
> Logger1: warning logger
> Logger1: trace logger|Logger3: info logger
> Logger2: info log
Re: 2.0 release triage
OK. I am going through the issues and assigning those I intend to look at to me. That doesn’t mean they are actively being worked on so if someone else wants to take ownership that is fine. Marking the issue as “In Progress” makes sense once I actually start working on something. Ralph On Mar 1, 2014, at 10:21 AM, Matt Sicker wrote: > I'd like it if the committers would assign or mark as "in progress" anything > they're working on or intend to work on in the short term. That way us > contributors don't duplicate any efforts! > > > On 28 February 2014 17:48, Ralph Goers wrote: > All I can tell you is what I do, although I suspect it is similar to what > others do. > > As I have time I go through the list of Jira issues and look for those that > a) look interesting or b) fit with the parts of Log4j I typically work on. I > don’t usually bother assigning the issue to me because I will either have a > solution in a few hours or determine that I don’t think what is being asked > for is workable, at which point I will put a comment in the issue. What is > unfortunate is that I don’t want to change the status to “Won’t Fix” until > the reporter has a chance to provide feedback and there really isn’t another > status (at least that I am aware) to set the issue to. > > That said, I probably should change my habits and go through the issues and > assign the ones I am interested in to me. In the end that would save me time > as I wouldn’t have to search all the open issues for whatever I want to work > on next. > > If you want to work on an issue go ahead and add a comment that you are > working on it. Of course, that doesn’t mean much if it isn’t followed by a > patch or requests for more info, etc. > > FWIW, I fixed the one remaining issue I considered a blocker to 2.0 GA > yesterday. However, I do need to go through the JMX code as the last time I > looked at it I saw several methods doing stuff I know won’t work. > > Ralph > > > On Feb 28, 2014, at 1:58 PM, Bruce Brouwer wrote: > >> So, because I can't assign any JIRA to myself (I don't have permission), >> should I just add a comment that says I'm working on it? >> >> Should I add comments to issues that I think should wait until after 2.0? Or >> is that going too far in my newbie status? >> >> I just find it hard to know where my effort will be best spent. There are >> currently only 12 issues that have a 2.0-like version assigned. That leaves >> a huge bucket of 107 issues and I'm left with very little idea on which of >> these to start with. Of this 107 issues with no fix version, 96 are >> unassigned. Where do I start such that I'm not wasting my time. I think it >> would be nice if someone closer to the project helped me out by identifying >> which issues they believed belonged in version 2.0 and which should wait >> until after 2.0, leaving them unassigned. >> >> Or would doing this cause problems because reporters might feel their issue >> isn't important enough to be worked on immediately? >> >> I am just trying to find an easier way to know how to help with 2.0 and I'm >> hoping others on the project might benefit as well by delaying discussions >> and debate for issues that don't belong in 2.0. Or is my desire to focus on >> 2.0 slightly misguided and I'm just not thinking of this in the open source >> way? Please educate me (but briefly so you have more time to work on 2.0 ;) >> >> >> >> On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma wrote: >> I like the idea of having a 2.1 version in Jira for items I intend to >> address after the 2.0 release. Items without version would (to me) mean >> either long-term items or items that I don't have the expertise for (or >> interest in, grin). >> >> One thing I find different in an open source project from working on a >> company project is assigning and scheduling issues. In an OS project you can >> pretty much only assign to yourself and schedule the items that you are >> planning to address yourself. (But as it's voluntary work, and other things >> come up, I find that even planning my own time to spend on log4j is not >> reliable...) >> >> So the Jira is all best effort IMHO. >> >> What seems to work ok for me is just picking items I'm interested in from >> the list of open Jiras, and assign them to myself (basically letting the >> rest of the team know that I'm currently working on this to avoid double >> work that would waste other people's time). Then provide the fix (with unit >> tests to prove the fix works) within some reasonable time. >> >> Remko >> >> Sent from my iPhone >> >> > On 2014/02/28, at 8:34, Bruce Brouwer wrote: >> > >> > One of the things that I find difficult right now is knowing what needs >> > the most attention for the purpose of releasing 2.0. There are actually >> > very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a >> > daunting number of issues that are not assigned a fix
[jira] [Resolved] (LOG4J2-413) PatternLayout option to not output ANSI escape codes if no Console is available
[ https://issues.apache.org/jira/browse/LOG4J2-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-413. - Resolution: Fixed Fix Version/s: 2.0-rc1 Forgot to resolve this a while back. > PatternLayout option to not output ANSI escape codes if no Console is > available > --- > > Key: LOG4J2-413 > URL: https://issues.apache.org/jira/browse/LOG4J2-413 > Project: Log4j 2 > Issue Type: Improvement > Components: Layouts >Affects Versions: 2.0-beta9 > Environment: Apache Maven 3.0.5 > (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500) > Maven home: C:\Java\apache-maven-3.0.5\bin\.. > Java version: 1.7.0_25, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_25\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory > Fix For: 2.0-rc1 > > Attachments: LOG4J2-413.diff > > > In some environments, like the Eclipse IDE, logging to the Java Console is > redirected to the GUI. In this context, ANSI escape codes mean nothing and > show up as "garbage" on the screen. > This condition can be detected, if java.lang.System.console() returns null, > like it does in Eclipse, then we should optionally not output ANSI codes. > It would be best to provide this as an option such that ANSI codes could > still be written to a file for later viewing on the console. -- 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
Re: 2.0 release triage
I'd like it if the committers would assign or mark as "in progress" anything they're working on or intend to work on in the short term. That way us contributors don't duplicate any efforts! On 28 February 2014 17:48, Ralph Goers wrote: > All I can tell you is what I do, although I suspect it is similar to what > others do. > > As I have time I go through the list of Jira issues and look for those > that a) look interesting or b) fit with the parts of Log4j I typically work > on. I don’t usually bother assigning the issue to me because I will either > have a solution in a few hours or determine that I don’t think what is > being asked for is workable, at which point I will put a comment in the > issue. What is unfortunate is that I don’t want to change the status to > “Won’t Fix” until the reporter has a chance to provide feedback and there > really isn’t another status (at least that I am aware) to set the issue to. > > That said, I probably should change my habits and go through the issues > and assign the ones I am interested in to me. In the end that would save > me time as I wouldn’t have to search all the open issues for whatever I > want to work on next. > > If you want to work on an issue go ahead and add a comment that you are > working on it. Of course, that doesn’t mean much if it isn’t followed by a > patch or requests for more info, etc. > > FWIW, I fixed the one remaining issue I considered a blocker to 2.0 GA > yesterday. However, I do need to go through the JMX code as the last time > I looked at it I saw several methods doing stuff I know won’t work. > > Ralph > > > On Feb 28, 2014, at 1:58 PM, Bruce Brouwer > wrote: > > So, because I can't assign any JIRA to myself (I don't have permission), > should I just add a comment that says I'm working on it? > > Should I add comments to issues that I think should wait until after 2.0? > Or is that going too far in my newbie status? > > I just find it hard to know where my effort will be best spent. There are > currently only 12 issues that have a 2.0-like version assigned. That leaves > a huge bucket of 107 issues and I'm left with very little idea on which of > these to start with. Of this 107 issues with no fix version, 96 are > unassigned. Where do I start such that I'm not wasting my time. I think it > would be nice if someone closer to the project helped me out by identifying > which issues they believed belonged in version 2.0 and which should wait > until after 2.0, leaving them unassigned. > > Or would doing this cause problems because reporters might feel their > issue isn't important enough to be worked on immediately? > > I am just trying to find an easier way to know how to help with 2.0 and > I'm hoping others on the project might benefit as well by delaying > discussions and debate for issues that don't belong in 2.0. Or is my desire > to focus on 2.0 slightly misguided and I'm just not thinking of this in the > open source way? Please educate me (but briefly so you have more time to > work on 2.0 ;) > > > > On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma wrote: > >> I like the idea of having a 2.1 version in Jira for items I intend to >> address after the 2.0 release. Items without version would (to me) mean >> either long-term items or items that I don't have the expertise for (or >> interest in, grin). >> >> One thing I find different in an open source project from working on a >> company project is assigning and scheduling issues. In an OS project you >> can pretty much only assign to yourself and schedule the items that you are >> planning to address yourself. (But as it's voluntary work, and other things >> come up, I find that even planning my own time to spend on log4j is not >> reliable...) >> >> So the Jira is all best effort IMHO. >> >> What seems to work ok for me is just picking items I'm interested in from >> the list of open Jiras, and assign them to myself (basically letting the >> rest of the team know that I'm currently working on this to avoid double >> work that would waste other people's time). Then provide the fix (with unit >> tests to prove the fix works) within some reasonable time. >> >> Remko >> >> Sent from my iPhone >> >> > On 2014/02/28, at 8:34, Bruce Brouwer wrote: >> > >> > One of the things that I find difficult right now is knowing what needs >> the most attention for the purpose of releasing 2.0. There are actually >> very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a >> daunting number of issues that are not assigned a fix version. >> > >> > From what I can see, much of the discussion on this mailing list is for >> issues that are not assigned a fix version. I'm guessing that many of the >> messages I am seeing could be delayed until after 2.0. How much of our >> attention is being spent on addressing issues that aren't contributing to >> releasing 2.0? >> > >> > I am willing to help. One of my roles is a JIRA admin in my day job. If >> I were given edit permission, I
[jira] [Assigned] (LOG4J2-469) FailoverAppender does not retry back for Primary target
[
https://issues.apache.org/jira/browse/LOG4J2-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-469:
--
Assignee: Ralph Goers
> FailoverAppender does not retry back for Primary target
> ---
>
> Key: LOG4J2-469
> URL: https://issues.apache.org/jira/browse/LOG4J2-469
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0-beta9
> Environment: JBoss 6.1.1, Spring-MVC, Log4j2 beta-9, Windows 7,
> Eclipse Kelper
>Reporter: Indrajit Pingale
>Assignee: Ralph Goers
> Labels: features
>
> Hi,
> In my product, I am using log4j2 for logging onto MySQL database. For
> that I am using JDBC as Primary and RollingRandomAccessFile as Secondary
> Appender.
> It works well and logs goes to Secondary appender when Primary appender
> fails (due to MySQL connection lost). But when MySQL connection comes back,
> it does not logs back to MySQL until I restart the JBoss Server.
> Is this a expected behavior? Or I am missing something in configuration
> file.
> Following is the my log4j2.xml file.
> {code:xml}
>
>
>
>ignoreExceptions="false" bufferSize="10">
>url="jdbc:mysql://localhost:3306/xxxid_db"
> username="root" password="xxwing" />
>
>
>
>
>
>
>
> fileName="${sys:jboss.server.log.dir}/app.log"
> filePattern="${sys:jboss.server.log.dir}/$${date:-MM}/app-%d{MM-dd-}-%i.log.gz">
>
> %d %p %c{1.} [%t] %m%n
>
>
>
>
>
>
>ignoreExceptions="false">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Thank You,
> Indrajit
--
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] [Resolved] (LOG4J2-473) Allow the use of log4j 1.2 appenders in log4j 2.0
[ https://issues.apache.org/jira/browse/LOG4J2-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-473. Resolution: Won't Fix I don't see the point of leaving this open as I'm not planning on implementing this and I seriously doubt anyone else will. > Allow the use of log4j 1.2 appenders in log4j 2.0 > - > > Key: LOG4J2-473 > URL: https://issues.apache.org/jira/browse/LOG4J2-473 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Tal Liron > > I understand that this is complex, as I've tried to implement it myself using > a wrapper class: it would indeed require translated various 2.0 classes to > 1.2 equivalents in order to properly send the log event. > However, it would be a very important contribution: projects like Hadoop use > lots of custom log4j 1.2 appenders, and as it stands they cannot be used with > 2.0 because of this. -- 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-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917141#comment-13917141
]
Ralph Goers commented on LOG4J2-519:
logger.fatal, logger.error, etc all go straight to AbstractLogger, which is why
you get the correct class name - the methods in AbstractLogger all use
AbstractLogger as the FQCN. However, the logger.diag and logger.notice methods
in Remko's example are all calling a logger.log method that does not contain an
FQCN, which is why the caller info is wrong.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the lis
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917137#comment-13917137
]
Ralph Goers edited comment on LOG4J2-519 at 3/1/14 5:52 PM:
in AbstractLoggerWrapper you will notice that the log method contains an fqcn
parameter. This value must contain the fully qualified class name of the class
that implements your logging. In this case I would guess that to be
LoggerWrapper. Log4j uses this to determine the caller information - it
traverses the stack until it finds the entry prior to the class named as the
fqcn. So if the fqcn is incorrect then the caller information will be
incorrect.
I presume you are referring to the code Remko supplied above. I haven't
reviewed it, but if you just copied that then obviously it has a problem with
regard to properly setting the fqcn.
was (Author: ralph.go...@dslextreme.com):
in AbstractLoggerWrapper you will notice that the log method contains an fqcn
parameter. This value must contain the fully qualified class name of the class
that implements your logging. In this case I would guess that to be
LoggerWrapper. Log4j uses this to determine the caller information - it
traverses the stack until it finds the entry prior to the class named as the
fqcn. So if the fqcn is incorrect then the caller information will be
incorrect.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLogg
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917137#comment-13917137
]
Ralph Goers commented on LOG4J2-519:
in AbstractLoggerWrapper you will notice that the log method contains an fqcn
parameter. This value must contain the fully qualified class name of the class
that implements your logging. In this case I would guess that to be
LoggerWrapper. Log4j uses this to determine the caller information - it
traverses the stack until it finds the entry prior to the class named as the
fqcn. So if the fqcn is incorrect then the caller information will be
incorrect.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917136#comment-13917136
]
vibin commented on LOG4J2-519:
--
Here is the code :
Wrapper class:
*
public final class DPLogger extends AbstractLoggerWrapper
{
private static final long serialVersionUID = 216489351472874L;
private static final Level NOTICE = Level.forName("NOTICE", 450);
private DPLogger(final Logger logger)
{
super((AbstractLogger) logger, logger.getName(),
logger.getMessageFactory());
}
/**
* Returns a custom Logger with the name of the calling class.
*
* @return The custom Logger for the calling class.
*/
public static DPLogger create()
{
final Logger wrapped = LogManager.getLogger();
return new DPLogger(wrapped);
}
/**
* Returns a custom Logger using the fully qualified name of the Class as
* the Logger name.
*
* @param loggerName The Class whose name should be used as the Logger name.
* If null it will default to the calling class.
* @return The custom Logger.
*/
public static DPLogger create(final Class loggerName)
{
final Logger wrapped = LogManager.getLogger(loggerName);
return new DPLogger(wrapped);
}
...
}
Test App:
*
public class DPTestLogger {
public static void main(String[] args) {
// TODO Auto-generated method stub
final DPLogger logger = DPLogger.create(DPTestLogger.class);
//DPLog logger = new DPLog(DPTestLogger.class);
try {
logger.fatal("test");
logger.error("test");
logger.warn("test");
logger.info("test");
logger.debug("test");
logger.trace("test");
logger.notice("Notice");
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Printed log
2014-03-01 12:45:22,300 FATAL c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,301 ERROR c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,301 WARN c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,301 INFO c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,301 DEBUG c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,301 TRACE c.h.i.d.t.DPTestLogger [main] test
2014-03-01 12:45:22,302 NOTICE c.h.i.d.l.w.DPLogger [main] Notice
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{i
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917134#comment-13917134
]
vibin commented on LOG4J2-519:
--
The example generated code given in this article doesn't contain FQCN
properly,I just followed the same. If it is required can you explain how to set
FQCN property ?
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom levels to support and their {{intLevel}} relative
> strength
> * whether to extend {{Logger}} (and keep the existing built-in methods) or
> have only methods for the custom log levels
> an
[jira] [Resolved] (LOG4J2-491) RollingFile Appender - callbacks when rolling
[ https://issues.apache.org/jira/browse/LOG4J2-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-491. Resolution: Won't Fix PatternLayout has been modified to accept and header and a footer that can contain a lookup pattern. As such there is no need for this enhancement. > RollingFile Appender - callbacks when rolling > -- > > Key: LOG4J2-491 > URL: https://issues.apache.org/jira/browse/LOG4J2-491 > Project: Log4j 2 > Issue Type: Wish > Components: Appenders >Affects Versions: 2.0-beta9 > Environment: Java 1.7, Linux >Reporter: Joe Merten > > I want this callbacks to add some custom info at the top of each logfile, > like the version string of my application, the application uptime and the > system uptime. And even writing some »bye, bye / eof« to the bottom of the > just closed logfile would also be fine. > See also: > * [LOG4J2-486] > * > [http://stackoverflow.com/questions/20819376/log4j2-rollingfile-appender-add-custom-info-at-the-start-of-each-logfile] > Currently I need to extend DefaultRolloverStrategy and wrap around > RolloverDescription and appender.rolling.helper.Action to place my code > (and therefore I also have to copy some factory code of > DefaultRolloverStrategy to support all config parameters etc.). Ok, this > approach currently works but it needs ~150 lines of code and is > maintenance-unfriendly eg. if DefaultRolloverStrategy gets more config > parameters in future versions. > The callbacks should provide at least the filename of the related logfile. > An access to the configured Layout of the related appender would also > helpful, so that the custom info could be correctly formatted (e.g. incl. > timestamp or matching for xml etc.). > I think there sould be 2 callbacks > * 1st one for after all outstanding writes to the old logfile has been done > (so thet I could add some stuff to the end of the old file), but before > things like compressing are performed > * 2nd one for to write my stuff to the top of the new logfile > Ok, there must be take care of Layout.getHeader/Footer() (which is used by > e.g. XMLLayout) considering if the callbacks should be called e.g. "inside or > outside of the xml root tags". > If I want to add my custom info as a kind of LogEvents, then the callbacks > should be called before writing the Layout.getFooter() and after writing > Layout.getHeader() to the file. > But if someone want to add custom info outside of the xml root tags (e.g. > someone might calculate a checksum over the logfile and write that to the > very last line of the file) then the callbacks must be called outside > header/footer. > For my current needs, I require the callbacks inside of header/footer > (although it not really matters for me while I currently only using > PatternLayout). > Bug finally that looks that we need callbacks for both cases. -- 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] [Resolved] (LOG4J2-496) Allow Layout header and footer to be configured in files and to contain properties.
[ https://issues.apache.org/jira/browse/LOG4J2-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-496. Resolution: Fixed Fix Version/s: 2.0-rc2 Assignee: Ralph Goers PatternLayout was modified to allow a header and footer to be specified that can contain a lookup pattern in revision 1573203. > Allow Layout header and footer to be configured in files and to contain > properties. > --- > > Key: LOG4J2-496 > URL: https://issues.apache.org/jira/browse/LOG4J2-496 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators >Affects Versions: 2.0-beta9 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.0-rc2 > > > In LOG4J2-491 the user is requesting to be able to insert his own custom > header and footer during rollover. The Layout header and footer were designed > for that purpose but currently can only be used to specify a static header or > footer. Furthermore, PatternLayout doesn't allow the header or footer to be > provided at all. -- 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] [Closed] (LOG4J2-496) Allow Layout header and footer to be configured in files and to contain properties.
[ https://issues.apache.org/jira/browse/LOG4J2-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-496. -- > Allow Layout header and footer to be configured in files and to contain > properties. > --- > > Key: LOG4J2-496 > URL: https://issues.apache.org/jira/browse/LOG4J2-496 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators >Affects Versions: 2.0-beta9 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.0-rc2 > > > In LOG4J2-491 the user is requesting to be able to insert his own custom > header and footer during rollover. The Layout header and footer were designed > for that purpose but currently can only be used to specify a static header or > footer. Furthermore, PatternLayout doesn't allow the header or footer to be > provided at all. -- 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-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917131#comment-13917131
]
Ralph Goers commented on LOG4J2-519:
Can you provide some sample code to demonstrate this?
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom levels to support and their {{intLevel}} relative
> strength
> * whether to extend {{Logger}} (and keep the existing built-in methods) or
> have only methods for the custom log levels
> and the tool generates the source code for the wrapper class that has exactly
> the required methods. Us
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917071#comment-13917071
]
vibin edited comment on LOG4J2-519 at 3/1/14 5:35 PM:
--
Found an issue while testing the custom log level, it does print incorrect
Class name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
was (Author: vibin_12):
Found an issue while testing the custom log level, it does print incorrect
Class name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
>
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917126#comment-13917126
]
Ralph Goers commented on LOG4J2-519:
I don't see how the log level would affect the class name. In your custom
logger did you set the FQCN properly?
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> error-prone: there are 14 methods for each built-in level. To provide
> comparable functionality for custom log Levels one would need to provide 14
> methods for each custom log Level.
> The proposal is to solve this by providing a tool that generates the source
> code for a wrapper class. The user can specify:
> * the fully qualified name of the class to generate
> * the list of custom levels to support and their {{intLevel}} relative
> strength
> * whether to extend {{Logger}} (and keep the existing built-in methods) or
> have only methods for the custom log levels
> and the tool generates the source code for th
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917071#comment-13917071
]
vibin edited comment on LOG4J2-519 at 3/1/14 3:58 PM:
--
Found an issue while testing the custom log level, it does print incorrect
Class name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
was (Author: vibin_12):
Found an issue while using a custom log level, it does print incorrect Class
name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achi
[jira] [Comment Edited] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917071#comment-13917071
]
vibin edited comment on LOG4J2-519 at 3/1/14 3:41 PM:
--
Found an issue while using a custom log level, it does print incorrect Class
name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
was (Author: vibin_12):
Fund an issue while using a custom log level, it does print incorrect Class
name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve t
[jira] [Commented] (LOG4J2-519) Custom/Extended Loggers
[
https://issues.apache.org/jira/browse/LOG4J2-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917071#comment-13917071
]
vibin commented on LOG4J2-519:
--
Fund an issue while using a custom log level, it does print incorrect Class
name, it prints WrapperClass name instead actual class where the logs are
originated.
Find example below:
The NOTICE level prints incorrect class name in the log file, it prints
WrapperClass name instead of "TestApp", any solution to this issue ?
2014-03-01 08:19:16,551 ERROR c.h.i.d.t.TesApp [main] test message
2014-03-01 08:19:16,551 WARN c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 INFO c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 DEBUG c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 TRACE c.h.i.d.t.TestApp [main] test message
2014-03-01 08:19:16,551 NOTICE c.h.i.d.l.w.LoggerWrapper [main] test message
Thanks.
> Custom/Extended Loggers
> ---
>
> Key: LOG4J2-519
> URL: https://issues.apache.org/jira/browse/LOG4J2-519
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
>Affects Versions: 2.0-rc1
>Reporter: Remko Popma
> Attachments: Generate.java
>
>
> {anchor:Extending}
> *[#Extending] the Logger interface*
> LOG4J2-41 added support for custom log Levels. Users can now log messages at
> the new custom level by passing the custom level to the {{Logger.log()}}
> method:
> {code}
> final Logger logger = LogManager.getLogger();
> final Level VERBOSE = Level.forName("VERBOSE", 550);
> logger.log(VERBOSE, "a verbose message");
> logger.log(VERBOSE, "another message");
> {code}
> However, custom levels are not as easy to use as the built-in levels: one
> needs to call the generic {{log()}} method and pass a {{Level}} parameter.
> Built-in levels on the other hand have a set of convenience methods on the
> Logger interface. For example, the Logger interface has 14 debug methods that
> support the DEBUG level:
> {code}
> debug(Marker, Message)
> debug(Marker, Message, Throwable)
> debug(Marker, Object)
> debug(Marker, Object, Throwable)
> debug(Marker, String)
> debug(Marker, String, Object...)
> debug(Marker, String, Throwable)
> debug(Message)
> debug(Message, Throwable)
> debug(Object)
> debug(Object, Throwable)
> debug(String)
> debug(String, Object...)
> debug(String, Throwable)
> {code}
> Similar method sets exist for the other built-in levels.
> Several people have expressed the desire to have the same ease of use with
> custom levels, so after declaring a custom VERBOSE level, we would like to be
> able to use code like this:
> {code}
> logger.verbose("a verbose message"); // no need to pass the VERBOSE level as
> a parameter
> logger.verbose("another message");
> {code}
> {anchor:Customizing}
> *[#Customizing] the Logger interface*
> In the above use case, convenience methods were _added_ to the Logger
> interface, in addition to the existing {{trace()}}, {{debug()}}, {{info()}},
> ... methods for the built-in log levels.
> There is another use case, Domain Specific Language loggers, where we want to
> _replace_ the existing {{trace()}}, {{debug()}}, {{info()}}, ... methods with
> all-custom methods.
> For example, for medical devices we could have only {{critical()}},
> {{warning()}}, and {{advisory()}} methods. Another example could be a game
> that has only {{defcon1()}}, {{defcon2()}}, and {{defcon3()}} levels.
> Finally, if it were possible to hide existing log levels, users could
> customize the Logger interface to match their requirements. Some people may
> not want to have a {{FATAL}} or a {{TRACE}} level, for example. They would
> like to be able to create a custom Logger that only has {{debug()}},
> {{info()}}, {{warn()}} and {{error()}} methods.
> {anchor:wrapper}
> *Proposal: Generate source code for a Logger [#wrapper]*
> Common log4j usage is to get an instance of the {{Logger}} interface from the
> {{LogManager}} and call the methods on this interface. This makes it hard to
> achieve the above customization; especially taking away existing methods is
> not possible.
> An alternative is for the user to create a wrapper class that exposes only
> the convenience methods for the desired log levels. When _extending_ the
> {{Logger}} API (_adding_ methods), this wrapper class could subclass
> {{org.apache.logging.log4j.spi.AbstractLoggerWrapper}}. When _customizing_
> the {{Logger}} API (_removing_ built-in methods), the wrapper class would
> simply not extend AbstractLoggerWrapper, so the only public methods would be
> the methods for the custom log levels.
> As the custom log Levels are not known in advance, Log4J cannot provide
> pre-built wrapper classes for these custom log Levels. However, we don't want
> to ask the users to hand-code such a wrapper class: this is cumbersome and
> er
