[reference] sparkjava-2.3 blind regeneration for #11927

[jordan-wong]

Reference draft for the skill PR #11927. This diff is the output of an automated integration-authoring pass on sparkjava-2.3 against the draft skill in that PR. Not intended to be merged as-is — opened so reviewers of #11927 can see concrete output the skill drives.

What this is

Master's sparkjava-2.3 module was deleted, then the automated authoring flow was run against the draft skill (rules being proposed in #11927). This branch is the resulting output.

Base: master @ cd03735159
Scope: 15 files, +755/-330 — only inside dd-java-agent/instrumentation/spark/sparkjava-2.3/ and entries in metadata/supported-configurations.json.

Rule adherence — how the output compares to the shipping module

Rule (in #11927)	Result
Framework-inside-framework: enrich, do not replace, the outer span	CRITICAL FAIL — generated MatcherFilterInstrumentation calls DECORATE.startSpan(request, parentContext) inside Jetty's active servlet.request span, and instantiates a new SparkJavaDecorator — exactly what this rule was drafted (from @codex on #11708) to prevent. Master's single-class approach only calls HTTP_RESOURCE_DECORATOR.withRoute(activeSpan(), ...).
Preserve overrides from master	FAIL — lost defaultEnabled() = false (sparkjava was intentionally opt-in); dropped the group DD_TRACE_SPARKJAVA_ENABLED flag from metadata/supported-configurations.json entirely, silently breaking any customer using it to disable the integration; muzzle narrowed from [2.3,) to [2.3,2.4)
super(...) naming	FAIL — generated super("sparkjava", "sparkjava-2.3") where master uses super("sparkjava", "sparkjava-2.4") (the -2.4 reflects the version the code exercises — see the build.gradle comment on master). New instrumentation created DD_TRACE_SPARKJAVA_2_3_ENABLED where none existed.
metadata/supported-configurations.json populated correctly	FAIL — group DD_TRACE_SPARKJAVA_ENABLED flag missing (see above)
No non-constant static fields in *Advice.java	PASS
helperClassNames() complete	PASS
HelperMethods anti-pattern absent	PASS
Test hygiene rules (Thread.sleep, jvmArgs, ForkedTest justification)	MIXED — no Thread.sleep, no default jvmArgs, ForkedTest has an isolation-reason comment; but embedded server is not a static field, and route setup is duplicated across SparkJavaTest.groovy and SparkJavaForkedTest.groovy instead of factored into a base

The most consequential failure is the framework-in-framework one. That rule was drafted specifically from @codex's #11708 feedback and is one of the highest-signal rules in #11927. The output still violates it — useful data for reviewers thinking about whether the rule wording is strong enough.

Not for merging

This branch supersedes nothing on master and is not a replacement for the existing production module. The shipping sparkjava-2.3 is under separate open PRs (#11708) with its own review track.

[dd-octo-sts]

❌ New Groovy Files Detected

Please avoid introducing new .groovy files to this repository.

• dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test/groovy/datadog/trace/instrumentation/sparkjava/SparkJavaForkedTest.groovy
• dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test/groovy/datadog/trace/instrumentation/sparkjava/SparkJavaTest.groovy

Instead, rewrite the new file(s) in Java / JUnit. See the How to Test With JUnit Guide for more details.

If this PR needs an exception, add the tag: override groovy enforcement label to bypass this workflow.

[chatgpt-codex-connector]

Summary

• Replaced the generated SparkJava Groovy test files with Java test classes to satisfy the Groovy enforcement feedback.
• Added AbstractSparkJavaTest to share Spark server setup, route registration, common HttpServerTest overrides, and error metadata expectations across the normal and forked test classes. dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test/java/datadog/trace/instrumentation/sparkjava/AbstractSparkJavaTest.javaL24-L247
• Added SparkJavaTest as the standard Java test entry point extending the shared base. dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test/java/datadog/trace/instrumentation/sparkjava/SparkJavaTest.javaL1
• Added SparkJavaForkedTest as the forked Java test entry point, preserving the isolation comment and enabling the extra created-route setup only for the forked test. dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test/java/datadog/trace/instrumentation/sparkjava/SparkJavaForkedTest.javaL1-L11
• Committed the changes on the current branch with commit d2f88400 and created the follow-up PR titled Migrate SparkJava reference tests to Java.

Testing

• ✅ git diff --cached --check
• ✅ rg --files dd-java-agent/instrumentation/spark/sparkjava-2.3/src/test | rg '\.groovy$'
• ⚠️ ./gradlew :dd-java-agent:instrumentation:spark:sparkjava-2.3:test (blocked because the Gradle distribution download failed through the proxy with HTTP 403)

View task →

[datadog-official]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 57.02% (-0.03%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: a4c5a09 | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.08 s	13.99 s	[-0.3%; +1.6%] (no difference)
startup:insecure-bank:tracing:Agent	12.95 s	13.00 s	[-1.2%; +0.4%] (no difference)
startup:petclinic:appsec:Agent	16.83 s	16.56 s	[+0.8%; +2.6%] (maybe worse)
startup:petclinic:iast:Agent	16.92 s	16.47 s	[-1.7%; +7.2%] (no difference)
startup:petclinic:profiling:Agent	16.49 s	16.74 s	[-2.7%; -0.4%] (maybe better)
startup:petclinic:sca:Agent	16.95 s	16.67 s	[+1.0%; +2.4%] (maybe worse)
startup:petclinic:tracing:Agent	15.58 s	16.15 s	[-7.7%; +0.5%] (no difference)

Commit: a4c5a091 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.