-
Notifications
You must be signed in to change notification settings - Fork 807
GUACAMOLE-2181: Improve readability of logs. #1136
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
GUACAMOLE-2181: Improve readability of logs. #1136
Conversation
|
@mike-jumper One question about these changes that I just want to confirm - when DEBUG-level logging is enabled, this will result in the abbreviated class names being included at all of the message levels (INFO, WARN, DEBUG, etc.), and not just for stack traces or DEBUG-level messages, correct? I think this is what I see in your output above, just want to verify, as I find that valuable as a developer. |
@necouchman Yep! |
…tensions are loaded.
If the WebSocket is closed while a message is on its way out, an IllegalStateException is thrown.
181e125 to
42f4503
Compare
necouchman
left a comment
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.
Just a couple of log message...that I wrote...that probably need some updating :-).
...uth-radius/src/main/java/org/apache/guacamole/auth/radius/AuthenticationProviderService.java
Show resolved
Hide resolved
...uth-radius/src/main/java/org/apache/guacamole/auth/radius/AuthenticationProviderService.java
Show resolved
Hide resolved
|
No longer part of these changes, but an earlier iteration involved creating a /**
* HashMap implementation that uses copy-on-write to allow efficient cloning.
* When an instance of ForkableHashMap has been copied using {@link #fork()},
* the parent and child both continue to refer to the same copy of their
* underlying data. If the parent (or child) is modified, only then does the
* parent (or child) create an independent copy of that underlying data.
* <p>
* For simplicity, this implementation DOES NOT permit modification via the
* collections/sets returned by {@link #values()}, {@link #keySet()}, or
* {@link #entrySet()}.
* <p>
* As with the standard HashMap, this implementation IS NOT threadsafe.
*
* @param <K>
* The type of key used to store/retrieve values within this map.
*
* @param <V>
* The type of values stored by this map.
*/
public class ForkableHashMap<K, V> implements Map<K, V> {
...
}It was a neat data structure that lives on in the git history as part of commit be53376 and might be handy in the future. |
We don't use WADL support and it has historically been implicitly
disabled through the lack of a JAXB implementation. Jersey warns of this
every time Guacamole starts up:
WARN: JAXBContext implementation could not be found. WADL feature is disabled.
This disables WADL explicitly.
The LDAP extension's guac-manifest.json refers to a German translation
in "de.json", but that translation file doesn't actually exist for LDAP,
hence the following warning at startup:
WARN: Overlay language resource "de" does not exist.
This corrects that warning by removing the erroneous reference.
This change performs significant automatic cleanup of our logging style. Previously, all log messages simply included an abbreviated class name for context:
The class name is a detail that's mainly helpful to developers, and there are other issues with readability:
To target messages more at administrators, these changes use an automatically determined "module" name for context (derived from context information on the call stack):
Stack traces are automatically omitted except when debug-level logging is enabled, in which case the abbreviated class name also returns:
The fact that this is now automatic means that the old style of manually logging twice:
can now be replaced with a single log statement:
and these changes update the rest of guacamole-client to do so.
These changes also silence the following confusing WebSocket error that can sometimes appear when a connection has closed:
This will now only appear at the debug level, handled as part of the WebSocket tunnel's overall logging of I/O errors, rather than propagating all the way up to Tomcat.
(Opening as a draft while I self-review this a bit.)