GRAYLOG - Chapter 1, Exercise 1 Solution
==========================================================
Why a Leading Wildcard Query Fails

PROBLEM
-------
Explain, using this chapter's own material, why a query like
class:*Controller would return zero results even if plenty of matching
log lines genuinely exist, and rewrite it into a form that would
actually work if the class names in question all started with the same
known prefix.

SOLUTION
--------
This chapter established that Graylog's Lucene-style search only
supports TRAILING wildcards (field:Foo*), not LEADING wildcards
(field:*Foo). class:*Controller puts the asterisk at the start of the
value, asking Graylog to match anything ENDING in "Controller" -
exactly the unsupported pattern. The query doesn't error out loudly; it
just silently returns zero results, which is what makes this gotcha
genuinely easy to miss mid-investigation.

If the real class names in question are known to share a common
prefix - for example, everything under the package
hwsdb.controller.* - the query can be rewritten to use a trailing
wildcard on that known, literal prefix instead:

    class:hwsdb.controller.*

ANSWER: class:*Controller fails because it's a leading wildcard, which
Graylog's search syntax doesn't support. If the real class names share
a known literal prefix, rewriting to class:hwsdb.controller.* (a
trailing wildcard on that known prefix) works - though note this
matches everything under that prefix, not specifically classes ending
in "Controller" - a genuinely different, narrower kind of match than
what the original query was trying to express.

----
WHY THIS WORKS AS AN ANSWER

This directly applies the chapter's own stated real limitation. The
underlying practical lesson: since you can't search backward from a
suffix, the real workaround is to search forward from whatever literal,
known starting text you actually have - converting an unsupported
"ends with" search into a supported "starts with" search, even though
the two aren't logically equivalent.