vp340 commented on code in PR #3373:
URL: https://github.com/apache/cxf/pull/3373#discussion_r3835708988
##########
rt/features/logging/src/main/java/org/apache/cxf/ext/logging/LoggingInInterceptor.java:
##########
@@ -71,6 +73,9 @@ public LoggingInInterceptor(PrintWriter writer) {
public LoggingInInterceptor(LogEventSender sender) {
super(Phase.PRE_INVOKE, sender);
+
+ //Make sure that the LIVE_LOGGING_PROP won't be propagated into the
ResponseContext from IN Messages
+ addResponseContextExcludedInProperty(LIVE_LOGGING_PROP);
Review Comment:
Hi @reta , I understand your point.
All module must be discern (I thought wrongly that the logging module could
be aware of the core one ... having his dependency).
Thanks a lot for all the lessons about design pattern in such big project
like cxf :) and for guiding me through all these solutions .
I'm glad at least we have discover the full picture about the problem!
So the only solutions remains acting on the single modules.
For me your solution in the logging module (change LIVE_LOGGING_PROP adding
true/false based on client/server) works fine and giving the results of the
test solve the ghost RESP_OUT.
If I were U, I would only consider to add the string "client/server" instead
of "true/false" in order to be more understandable for the posterity ( but is
up to U ... U are the pro one :) ).
In the core module...the other solution that I thought right now (to be
taken with a grain of salt) is to change approach in the ClientImpl ... and add
a sort of white-list of the properties that needs to be propagated in the
ResponseContext. But this will change completely the actual policy from... let
pass all and remove one ....to ... let pass only the needed.
I don't have the knowledge to know what are the properties needed and I
don't even know if this is a suitable idea...
If U find it ok and want to try to implement it let me know ...I could
prepare at least the skeleton where to add the white-list properties if U want.
((In the last message where U said the you have many clients I wondered if
this 'problem' of propagating all props into ResponseContext is common for
other Client-s other than the ClientImpl... if so this last idea is less
appetizing and would need to change all ...or find some common point to put all
the props if they are the same)).
Let me know what U think.
If the last idea isn't suitable in my opinion we can merge your
https://github.com/apache/cxf/pull/3372 .
Have a great job!
Valentino Porta
--
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]
