-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding HttpLogOptions for Logging improvements #5688
Conversation
...pconfiguration/src/main/java/com/azure/data/appconfiguration/ConfigurationClientBuilder.java
Outdated
Show resolved
Hide resolved
...onfiguration/src/test/java/com/azure/data/appconfiguration/ConfigurationAsyncClientTest.java
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLogOptions.java
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLogOptions.java
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLogOptions.java
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLogOptions.java
Outdated
Show resolved
Hide resolved
/** | ||
* Logs everything in QUERY PARAMS. | ||
*/ | ||
QUERY_PARAMS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't quite make sense - if the user opts in for QUERY_PARAMS, that means that they can't also get BODY or BODY_AND_HEADERS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so should we keep the requirement to log query params on only BODY or BODY_AND_HEADERS or both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BASIC
indicates log url (that includes query parameter) and skip headers & body. Wondering why we need QUERY_PARAMS
enum option for a specific part of url, Does guideline enforce it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the guideline enforces to have the QUERY_PARAMS
enum. It can be removed, but still, not sure if we need BODY_AND_HEADERS
with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, remove QUERY_PARAMS
. Leave the rest as-is I would think.
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLoggingPolicy.java
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLoggingPolicy.java
Outdated
Show resolved
Hide resolved
sdk/core/azure-core/src/main/java/com/azure/core/http/policy/HttpLoggingPolicy.java
Outdated
Show resolved
Hide resolved
@@ -115,7 +120,40 @@ public HttpLoggingPolicy(HttpLogDetailLevel detailLevel, boolean prettyPrintJSON | |||
return reqBodyLoggingMono; | |||
} | |||
|
|||
private Function<HttpResponse, Mono<HttpResponse>> logResponseDelegate(final ClientLogger logger, final URL url, | |||
private void formatAllowableHeaders(Set<String> allowedHeaderNames, HttpRequest request, ClientLogger logger) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@samvaity / @JonathanGiles does guideline proposes different meaning for empty vs null
value for allowedHeaderNames
? i.e. something like empty set means redact all headers and null means log all headers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also thinking if we should add something like a "*", to say log all headers maybe..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At present null and empty set should mean the same thing - to not print any headers.
ff415ac
to
2feba11
Compare
9d028c7
to
9034f2a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just a few minor things to consider.
policies = new ArrayList<>(); | ||
httpLogOptions = new HttpLogOptions().setLogLevel(HttpLogDetailLevel.NONE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It probably makes sense to just have the log level be NONE by default.
public ConfigurationClientBuilder httpLogDetailLevel(HttpLogDetailLevel logLevel) { | ||
httpLogDetailLevel = Objects.requireNonNull(logLevel); | ||
public ConfigurationClientBuilder httpLogOptions(HttpLogOptions logOptions) { | ||
httpLogOptions = Objects.requireNonNull(logOptions, "Http log options cannot be null."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably allow null now that I think about it - this lets the user clear out the configuration in the builder so that the next time they call build, they will get an HttpLoggingPolicy with null options. This also means you need to have HttpLoggingPolicy know what to do if the options are null!
* @throws NullPointerException If {@code logLevel} is {@code null}. | ||
*/ | ||
public HttpLogOptions setLogLevel(final HttpLogDetailLevel logLevel) { | ||
this.logLevel = Objects.requireNonNull(logLevel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe rather than require non-null, if null is passed in just set it to NONE. Be sure to document that though.
*/ | ||
public HttpLoggingPolicy(HttpLogDetailLevel detailLevel, boolean prettyPrintJSON) { | ||
this.detailLevel = detailLevel; | ||
public HttpLoggingPolicy(HttpLogOptions httpLogOptions, boolean prettyPrintJSON) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious if, outside of unit tests, anyone calls this constructor. If no one does, I would like to see this constructor made package-private for now, because this kind of boolean config should be in the HttpLogOptions object.
// | ||
Mono<Void> reqBodyLoggingMono = Mono.empty(); | ||
// | ||
if (detailLevel.shouldLogBody()) { | ||
if (httpLogOptions.getLogLevel().shouldLogBody()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whenever I see a method call (like getLogLevel()
) multiple times I prefer to see it referred to in a local variable.
sb.append(REDACTED_PLACEHOLDER); | ||
} | ||
} | ||
logger.info(sb.toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a newline or whitespace included in this concatenation operation?
} | ||
logger.info(sb.toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This header concatenation code should be centralised in this class rather than duplicated for request and response headers.
Reference #4154