Most notably, we want to use the plus character in URI schemes. By only
checking the first character of the scheme registration, we can better
fullfil our contract and better distinguish between schemes and class
names of registered Adapters.
If we were to fall through, undefined schemes would always end up as a
file adapter. This is generally undesired since it hides the fact that
we have not found a suitable adapter. Most of the time, this will be a
configuration error which should be reported early.
If a user still wants to create a file adapter with a filename that
looks like a URI, they can create a Rackstash::Adapter::File object
manually.
Now you can define optional filters which only run if some condition is
true or false. This can be used to e.g. update fields depending on some
tags being present in the event.
This removes the requirement that filters need to be defined in the
Rackstash::Filters namespace in order to be usable with a short name.
Filters can be registered with an arbitrary name.
As before, raw blocks / procs can be defined as ad-hoc filters.
Using the ClassRegistry, we can register short names for filter and
encoder classes so that they can be specified in a shorter and more
readable way during creation of the logger.
We extract some internal emthods to make the truncation flow clearer,
i.e. first we run the selectors, then we truncate the message, then we
insert the ellipsis message (if required).
This ensures that other middlewares whi want to log to the default
rack.errors stream will log to a sensible location instead of the usual
default of raw STDOUT or STDERR.
If a line is completely empty, it is not useful to log it at all since
it would be invisible on the created logstream anyway. If we get passed
an empty String from the encoder, we can thus silently ignore it.
If an event's message is completely empty (usually because there was
nothing logged at all), it isn't very useful to output this bare marked
up message at all. We thus ignore it and pass it along unchanged in the
Message encoder.
Note that we still add tags for messages consisting of other whitespace
like e.g. a newline added from a formatted empty message added to a
Logger.
The middleware can be used in a Rack appliction wrap all log messages
emitted to the logger during a single request in a single emitted log
event. This ensures that all data concerning the request, including log
messages as well as additional fields and tags are logged as one single
event.
This ensures that the data is kept as a whole when the log event is
handled by later systems like Logstash. Each request can be analyzed as
a whole without having to group or parse complex multi-line log formats.
