[
https://issues.apache.org/jira/browse/LOG4J2-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050634#comment-14050634
]
Ralph Goers edited comment on LOG4J2-695 at 7/2/14 7:58 PM:
------------------------------------------------------------
Ulitmately what I think doesn't really matter since I don't work for your
employer.
Using a custom logger is an option, but is really something I would only do as
a last resort. If you want to standardize on the messaging the best way to do
that is to implement your own custom Message and possibly a Layout.
FWIW, Splunk can handle almost anything. IMO, the best way to integrate with
splunk would be to use the Log4j API and either
1. Create one or more custom Messages that wrap MapMessage. Format these so
splunk can easily parse them. FWIW, Splunk can easily handle the
StructuredDataMessage formatted with the RFC5424Layout. I've done that.
2. Leverage the ThreadContext. At my former employer we wrapped that with a
class that contained a bunch of static methods like setProductName(),
setUserId(), setClientId(), etc. In a web app the application can set most of
this information in a servlet filter and then it is available in every log
event. That will automatically become part of the RFC5424Layout if you want.
Then all the key value pairs you want in Splunk are there.
In short, I agree with what you want to do. I just don't think a custom logger
is the correct way to do it. Log4j 2 already supports what you want.
Also, I should point out that in the Flume Appender sub-project there is a UUID
class. It performs pretty well - in the unit test there is one that will tell
you how it performs.
was (Author: ralph.go...@dslextreme.com):
Ulitmately what I think doesn't really matter since I don't work for your
employer.
Using a custom logger is an option, but is really something I would only do as
a last resort. If you want to standardize on the messaging the best way to do
that is to implement your own custom Message and possibly a Layout.
FWIW, Splunk can handle almost anything. IMO, the best way to integrate with
splunk would be to use the Log4j API and either
1. Create one or more custom Messages that wrap MapMessage. Format these so
splunk can easily parse them. FWIW, Splunk can easily handle the
StructuredDataMessage formatted with the RFC5424Layout. I've done that.
2. Leverage the ThreadContext. At my former employer we wrapped that with a
class that contained a bunch of static methods like setProductName(),
setUserId(), setClientId(), etc. In a web app the application can set most of
this information in a servlet filter and then it is available in every log
event. That will automatically become part of the RFC5424Layout if you want.
Then all the key value pairs you want in Splunk are there.
In short, I agree with what you want to do. I just don't think a custom logger
is the correct way to do it. Log4j 2 already supports what you want.
> Custom Logger with restrictions on existing methods
> ---------------------------------------------------
>
> Key: LOG4J2-695
> URL: https://issues.apache.org/jira/browse/LOG4J2-695
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Reporter: SIBISH BASHEER
> Labels: customlogger
> Attachments: AppAsyncMain.java, CustomLogger.java, CustomLogger.java,
> final code custom logger.zip
>
>
> I have been looking at the Custom/Extended logger discussions. But none of
> them seems to fulfil what i am looking for.
> 1) I want custom methods as below:
> {code}
> private static CustomLogger logger =
> CustomLogger.getLogger(AppAsyncMain.class);
>
> logger.info( transaction_id, app_name + event_name +
> "inside the loop" + "inside the loop of
> the sample app" +
> "success" + "looped in" + "loop_count" +
> String.valueOf(i));
> {code}
>
> log:
> {code}
> 2014-06-30 16:09:28,268 log_level="INFO" thread_name="main"
> class_name="com.custom.samplelog4j.AppAsyncMain"
> transaction_id="79ea1071-9565-405a-aa18-75d271694bf2"
> event_id="dd5c69c0-4400-41fd-8a2e-5d538d8e8c9b" app="Sample Logging SDK App"
> event_name="Sample Event" action="start of sample app" desc="start of api"
> result="success" reason="start" token="abcdefg" alias="a...@gmail.com"
> {code}
>
> 2) I want to show warning in existing logger methods so the teams using the
> custom logger doesn't use these methods other than for testing:
> {code}
> logger.info("start of statement");
> {code}
>
> log:
> {code}
> 2014-06-30 16:12:31,065 log_level="INFO" thread_name="main"
> class_name="com.custom.samplelog4j2.AppAsyncMain" start of statement
> customlogger_warning="method not recommended for production use"
> {code}
>
> 3) Custom validations for the fields:
> {code}
> private static String validateFields(String app_name, String event_name,
> String action, String desc, Result result, String
> reason) {
> String validateStatus = "";
> if (!ValidateAppName(app_name)) {
> validateStatus = "app_name";
> } else if (!ValidateEventName(event_name)) {
> validateStatus = "event_name";
> } else if (!ValidateAction(action)) {
> validateStatus = "action";
> } else if (!ValidateDesc(desc)) {
> validateStatus = "desc";
> } else if (!ValidateReason(result, reason)) {
> validateStatus = "reason";
> }
> return validateStatus;
> }
> {code}
> Options tried:
> 1.
> * extended ExtendedLoggerWrapper
> * created the map of the Custom logger
> * This option was failing because of "writing to a closed appender"
> * Attached is the code "CustomLogger.java"
>
> 2. Modified the AbstractLogger in Trunk and added the below methods:
> {code}
> @Override
> public void info(final String message) {
> String updtMessage = message + " amexlogger_error=\"Incorrect method
> used\"";
> logIfEnabled(FQCN, Level.INFO, null, updtMessage, (Throwable) null);
> }
> public void info(final String transactionId, final String app_name, final
> String event_name, final String action, final String desc, final String
> result, final String reason, final String... moreFields) {
> String message = "transaction_id=" + transactionId + " " + "app_name="
> + app_name + " " + "event_name=" + event_name + " " + "action=" + action;
>
> logIfEnabled(FQCN, Level.INFO, null, message, (Throwable) null);
> }
> {code}
> I don't want to modify the methods inside the log4j-api.
>
> Please help me with the correct approach on how to use log4j2 for this
> usecase.
> Thanks
> Sibish
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
