vp340 commented on code in PR #3343:
URL: https://github.com/apache/cxf/pull/3343#discussion_r3695881881
##########
rt/features/logging/src/main/java/org/apache/cxf/ext/logging/AbstractLoggingInterceptor.java:
##########
@@ -25,20 +25,21 @@
import java.util.regex.Pattern;
import org.apache.cxf.common.util.PropertyUtils;
-import org.apache.cxf.ext.logging.event.DefaultLogEventMapper;
-import org.apache.cxf.ext.logging.event.LogEvent;
-import org.apache.cxf.ext.logging.event.LogEventSender;
-import org.apache.cxf.ext.logging.event.PrettyLoggingFilter;
+import org.apache.cxf.ext.logging.event.*;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Exchange;
import org.apache.cxf.message.Message;
import org.apache.cxf.phase.AbstractPhaseInterceptor;
+import static
org.apache.cxf.ext.logging.event.DefaultLogEventMapper.normalizeFlow;
+
public abstract class AbstractLoggingInterceptor extends
AbstractPhaseInterceptor<Message> {
public static final int DEFAULT_LIMIT = 48 * 1024;
public static final int DEFAULT_THRESHOLD = -1;
public static final String CONTENT_SUPPRESSED = "--- Content suppressed
---";
protected static final String LIVE_LOGGING_PROP =
"org.apache.cxf.logging.enable";
+ protected static final String IDEMPOTENT_LOGGING_PROP =
"org.apache.cxf.idempotent.logging."; // the EventType (flow) and ExchangeId
will be concatenated
Review Comment:
Hi @reta ,
thank you for the reply!
I added as you requested an example project
https://github.com/vp340/cxf-log-example to the JIRA ticket where I develop a
simple ExampleService that simulate the error-prone situation.
I added in the last JIRA comment a more detailed explanation. :)
If you have any problem to run it locally let me know and I'll try to help
you. (I'm currently on vacation, but I will try to reply asap :D )
I prepared wiremock configuration and a soapUI project (or if U prefer the
endpoint and the raw request) .
If U go to src/main/resources/spring/example/v1/route-context.xml ... and
uncomment the processor U can make the RESP_OUT log reapper as I described in
the JIRA ticket.
As i wrote in the comment, I undestand that adding the
IDEMPOTENT_LOGGING_PROP can be "confusing", but so is not finding the RESP_OUT
log because a generic property has already been set somewhere else and the
framework propagates it, if U don't manually intervene .
My goal with the IDEMPOTENT_LOGGING_PROP was to fullfill the use case "not
log twice" without using the same property used to disable completely the log
from the Bus (and that can lead to these sneaky situations ) .
In my project it worked fine without adding manual processor.
Hope it helps. Keep me updated :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
