dropwizard / dropwizard/dropwizard
Request logging of user ID and thread name is broken
@accwebs is already working on this.
Since Sep 2, 2026.
- Dominant language
- Java
- Stars
- 8.6k
- Forks
- 3.4k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 17
Description
At present, with Logback Access's request logging implementation, Dropwizard request logs fail to log a few fields. After some extensive testing, the affected fields are:
- user ID
- thread name
Other bugs:
- 'response header' logging logs "" (empty) instead of - when the header is not present.
- (Where the 'request header' logging DOES log a dash.)
- request/response content logging - when enabled - does not honor character encodings
- the IAccessEvent.getRequest/getResponse's decision to return a fake HttpServletRequest/HttpServletResponse breaks esoteric features in logback-access like
AccessEventDiscriminator. This can't be wired up in Dropwizard today best I can tell, but it's sloppy.
The source of the user ID problem is again the RequestWrapper class in the logback-access-jetty12 library:
@Override
public String getRemoteUser() {
return null;
}
@Override
public boolean isUserInRole(String role) {
return false;
}
@Override
public Principal getUserPrincipal() {
return null;
}
Separately, the lack of logging "thread name" come down to simply not calling AccessEvent.setThreadName() in the RequestLogImpl/LogbackAccessRequestLog log(...) implementation (neither implementation does this). Obviously this is not nearly as much of a concern as the lack of user logging.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.