With this logging tag one can easily see in the log file which logs have
been triggered by the plugin. For traces this is interesting because
then for actions such as loading files, doing index queries etc. one can
see if they have been triggered by a plugin. E.g. if there is an
extensive number of index queries that are triggered by a plugin we want
to see this in the trace.
Such logging tags are mostly useful for extension points that are likely
to have complex or expensive implementations. We may not want to set
such a logging tag for extension points which only have trivial
implementations.
Setting the logging tag with the plugin name when an extension point is
invoked is done by opening a trace context. To invoke extension points
with such a trace context they should be invoked through a plugin
context. The plugin context can be directly injected. Instead of
injecting DynamicItem/DynamicSet/DynamicMap you can now inject
PluginItemContext/PluginSetContext/PluginMapContext.
The plugin context classes offer methods to invoke the extension
points that automatically set the trace context. In addition they
provide functionality for catching and logging exceptions from plugins.
This makes the logging and exception handling for plugin invocations
more consistent across the code base and removes the need to have code
for this in multiple places.
Since exception handling with plugin contexts is easy now more plugin
invocations handle exceptions now which makes Gerrit more resilient
against plugin failures.
This change adapts calls to most important extensions points, such as
validators and listeners.
Change-Id: Iab41d0059049f06ca41b697e93aa6a1f9668de5b
Signed-off-by: Edwin Kempin <ekempin@google.com>
5eb0219eb3