You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
st-json/1: additive structured members so the OTel mapping needs no string parsing #268
Mapping st-json/1 to OpenTelemetry (#136) leaves three rows lossy. In each, a consumer has to parse a display string:
error.type is the simple class name (NullPointerException). semconv exception.type wants the fully-qualified name.
error.culprit.frame is a display string, e.g. OrderService.confirm(OrderService.java:87). Getting code.function.name / code.line.number out of it means parsing.
env is one string (app=shop-api 1.4.2 (git 7e3c1f) | java 21 | profile=dev | linux). service.name, service.version and deployment.environment.name have to be split out of it.
Proposal, additive only (FORMAT.md §6, so no format bump; the schema is open and the new members are optional):
error.typeName (FQN), next to error.type.
error.culprit.className / methodName / fileName / lineNumber, using the same names as the repro.* members.
envInfo: {app, version, gitSha, profile, java, os}, next to env.
Cost: JsonReportRenderer, the schema, the goldens, the drift test, and the §7 example. st/1 text is unchanged. Existing members are not renamed.
Activity