Realizes COMMONS-13–COMMONS-15.
Observability in commons is two things: the security-event surface (commons.events) and
the metric identifiers (commons.metrics). Both are defined once, carry no Micrometer
dependency, and are wired to Micrometer by each Quarkus extension.
SecurityEventCounter and the security-event types live in commons.events so validation
and the client share one event surface (COMMONS-13).
-
SecurityEventCounter— a thread-safe, highly concurrent counter keyed by event type; no Micrometer dependency (so the base layer stays dependency-light). -
SecurityEventCounter.EventType— the enumerated events, each carrying anEventCategory. -
EventCategory—INVALID_STRUCTURE,INVALID_SIGNATURE,SEMANTIC_ISSUES— usable by an edge to choose a response (COMMONS-14).
Because commons must not depend on validation (the
ArchUnit boundary), the event types carry no compile
link to validation’s log-message registry. The correlation with JWTValidationLogMessages
numbering is maintained by convention and documented in the single global
Log Messages registry, not by a cross-layer type reference.
Quarkus extensions expose the counter as before — the move is a package relocation, not a behavioural change.
Metric identifiers / contracts under the sheriff.token.* namespace are defined once in
commons.metrics (COMMONS-15). The identifiers are
plain constants / descriptors with no Micrometer dependency; each Quarkus extension binds
them to a MeterRegistry.
This keeps the metric contract stable across the validation and client capabilities and avoids duplicating identifier strings per extension.
Logging stays the global LogMessages registry — it is not a commons concern and is not split per capability. Security events and metrics are the commons observability surface; log records remain the project-wide registry.
-
Error-model specification — categories feed the RFC 9457 mapping