toffentoffen opened a new pull request, #13918:
URL: https://github.com/apache/skywalking/pull/13918
### Fix two independent bugs that break custom layers end-to-end. Closes
#13917.
- [x] Add a unit test to verify that the fix works.
- [x] Explain briefly why the bug exists and how to fix it.
Custom layers (declared without modifying OAP source — #13856 / #13883) were
broken in two independent ways. Either one alone prevents a custom layer from
working.
**Bug 1 — MAL v2 compiler cannot compile `Layer.nameOf('NAME')`**
A custom layer has no generated `Layer.*` static field, so
`Layer.nameOf('NAME')` is the documented way to reference it
(`docs/.../mal.md`). The v1 (Groovy) compiler evaluates it natively. The v2
compiler's grammar models only the static-*field* form (`enumRef : IDENTIFIER
DOT IDENTIFIER`, e.g. `Layer.GENERAL`); `Layer.nameOf('X')` was instead
mis-parsed as a metric named `Layer` with a `.nameOf("X")` method chain, and
codegen emitted `_Layer.nameOf("X")` against `SampleFamily`, failing with:
```
javassist.CannotCompileException: [source error] nameOf(java.lang.String)
not found in
org.apache.skywalking.oap.meter.analyzer.v2.dsl.SampleFamily
```
Fix is in the parser → AST → codegen layer (not the grammar, to avoid the
unsolvable `ID.ID(STRING)` ambiguity between `Layer.nameOf('x')` and a real
`metric.method('x')` — only the known-enum-type set distinguishes them).
`MALScriptParser` now reinterprets the `EnumType.method('arg')` shape — keyed
on `MALCodegenHelper.ENUM_FQCN`, so real `metric.method('x')` calls are
untouched — into a new `EnumStaticCallArgument`, and `MALMethodChainCodegen`
emits a static call on the enum FQCN.
Tests: `MALScriptParserTest` (parse → `EnumStaticCallArgument`, plus a
negative guard that non-enum `metric.method('x')` is unaffected) and
`MALClassGeneratorTest` (generated source emits `Layer.nameOf("...")` and
compiles). All 1268 bundled-rule execution tests still pass (no rule uses this
form today, which is why CI never caught it).
**Bug 2 — `layer-extensions.yml` bundled in the jar shadows the operator's
`config/` copy**
`layer-extensions.yml` (operator-managed, documented as living in `config/`)
was packaged inside `skywalking-oap.jar` and not shipped to the distribution
`config/`. The launch script (`dist-material/bin/oapService.sh:38-41`) prepends
every `oap-libs/*.jar` to `CLASSPATH`, leaving `config/` last, so
`ResourceUtils.read("layer-extensions.yml")` →
`getClassLoader().getResource(...)` deterministically resolved the empty
jar-bundled template (`layers: []`) and silently ignored the operator's file —
custom layers declared there never registered.
Fix: add `layer-extensions.yml` to the `maven-jar-plugin` `<excludes>`
(`oap-server/server-starter/pom.xml`) and to the assembly `<includes>`
(`apm-dist/src/main/assembly/binary.xml`), so it follows the same
exclude-from-jar + copy-to-`config/` packaging as every other operator-editable
config. Verified by rebuilding `skywalking-oap.jar` and confirming the file is
no longer present.
---
- [x] If this pull request closes/resolves/fixes an existing issue, replace
the issue number. Closes #13917.
- [x] Update the [`CHANGES`
log](https://github.com/apache/skywalking/blob/master/docs/en/changes/changes.md).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
