[
https://issues.apache.org/jira/browse/LOG4J2-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048570#comment-14048570
]
Ralph Goers edited comment on LOG4J2-695 at 7/1/14 6:33 AM:
------------------------------------------------------------
I have a couple of comments as I implemented pretty much this exact scenario
for my former employer.
1. You are mistaken to think that creating objects that are short lived will
impact performance. It won't. Java's garbage collection since Java 6 handles
this very well. I should also point out that Log4j is going to require that a
Message be created for every log event regardless. If you don't pass one in one
will be created under the covers for you.
2. The StructuredDataMessage is quite useful for what you are doing.
At my former employer we created a "catalog" of events and the attributes that
went with them. We used that catalog to generate a Java interface for each
event. We created a Java proxy that populated the StructuredDataMessage as
applications called the setter methods on the interface. Data from the catalog
was used to validate the data. Once all the fields were populated the
application would then call EventLogger.logEvent(msgbuilder.getMessage()). This
accomplished virtually everything you are asking for and performed very well
and required no customization of Log4j - primarily because it was designed to
handle this exact use case.
The issue here is that you seem to be focused on only a single way of solving
the problem.
was (Author: ralph.go...@dslextreme.com):
I have a couple of comments as I implemented pretty much this exact scenario
for my former employer.
1. You are mistaken to think that creating objects that are short lived will
impact performance. It won't. Java's garbage collection since Java 6 handles
this very well.
2. The StructuredDataMessage is quite useful for what you are doing.
At my former employer we created a "catalog" of events and the attributes that
went with them. We used that catalog to generate a Java interface for each
event. We created a Java proxy that populated the StructuredDataMessage as
applications called the setter methods on the interface. Data from the catalog
was used to validate the data. Once all the fields were populated the
application would then call EventLogger.logEvent(msgbuilder.getMessage()). This
accomplished virtually everything you are asking for and performed very well
and required no customization of Log4j - primarily because it was designed to
handle this exact use case.
The issue here is that you seem to be focused on only a single way of solving
the problem.
> 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: CustomLogger.java
>
>
> 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
