[CXF-9233] Ghost RESP_OUT log - #3343
Conversation
…(REQ_IN/REQ_OUT/RESP_IN/RESP_OUT)... Replacing the general logging enable properties that could be present from other flow if the same Message object is reused from underlying framework
…s set from previous backend-client call! :)
Introduce another properties for idempotent logging
| 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 |
There was a problem hiding this comment.
Thanks for the pull request @vp340 , I would advice against introducing yet another property, not only it becomes very confusing, it also difficult to figured out where all these different properties are coming from. I will try to spend some time looking into the problem, if you could attach a simple reproducer to the JIRA ticket, that would be great to understand the issue in context. Thank you.
There was a problem hiding this 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 :)
There was a problem hiding this comment.
Thanks a lot @vp340, I am off this week, will surely pick it up when I am back. My apologies, thank you
2 participants
Pull Request related to Jira: [CXF-9233] AbstractLoggingInterceptor.LIVE_LOGGING_PROP already set in the message properties, so RESP_OUT log is disable :(