[
https://issues.apache.org/jira/browse/LOG4J2-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050472#comment-14050472
]
SIBISH BASHEER commented on LOG4J2-695:
---------------------------------------
Hi Ralph,
Yes, if my usecase was to send some events to Splunk, your approach is good.
Our direction is to have each and every log statement to be in Splunk and don't
want the teams to use any methods from log4j directly. When we give more
freedom to the users, we are having very inconsistent logging and are spending
lot of time manually asking them to correct it. Considering that, do you think
using the Remko's approach is ok?
Hi Remko,
Thanks a lot for the detailed comments. Super helpful. Only Happy about
constructive criticism. Yes, developers will be restricted not to use log4j
directly and log only via CustomLogger. Every single log statement will be
moved to Splunk in all my applications, so we dont want any log which is not
Splunk compatible.
CustomLogger:
1) revive the trace and debug levels - will add it
2) revive the ability to log stack traces - will see if i can add a Splunk
compatible method for this
3) revive the ability to have parametrized logging - i won't give this freedom
to the team as it will result in inconsistent logging
4) will change to customlogger_warning="log not compatible with Splunk"
implementation style
1) "The class declared as lowercase customLogger" : Actually it is
CompanyNameLogger. I just did a string replace when i uploaded to generalize
it. So that was a typo.
2) Some private methods start with uppercase. - Will change it
3) Some variable names use underscore to separate words - I kept it that way so
developers are clear on what key value pairs they will generate. Only those key
variable names, i didn't follow the camelCase.
4) static final int stringBuilderInitialCapacity is using camelCase - will
change it to INITIAL_CAPACITY
5) The validate... methods could be rewritten as one-liners: Will change this
6) Result.success and Result.failure - will change
Performance:
1) The current logic creates the formattedString regardless of whether the
level is enabled. I would recommend first checking if (logger.isEnabled(level,
...)) before creating the formattedString object.
- Probability of calling the logger when it is not enabled is very very rare or
rather won't happen. So that will be an unnecessary if condition right?
2) UUID - will see if i can make it once per a logical group and use sequence
number for per event
> 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
