Extending jPOS structured audit logs
jPOS 3 introduced structured audit logging as a first-class feature: instead of writing only text lines, a log event can carry typed payloads such as start, stop, deploy, connect, disconnect, txn, and so on.
That structure is what makes tools such as the jPOS Log Viewer possible. The viewer can filter, facet, correlate, and render events because it is not guessing meaning from text. It is reading fields.
Until now, however, those typed audit events were effectively limited to the event classes shipped inside jPOS itself. That was fine for core runtime events, but it was not enough for real applications.
A jPOS-EE module, an application module, or a customer-specific extension may have its own operational event worth logging in a structured way:
- an HTTP access event from QRest,
- an authentication event from a web application,
- a business workflow transition,
- a settlement file import,
- a reconciliation result,
- a domain-specific warning that deserves first-class fields.
Those should not have to be flattened into strings. They should be allowed to live next to the built-in jPOS audit events.
That is now possible.