[reference] sparkjava-2.3 blind regeneration for #11927#11936
[reference] sparkjava-2.3 blind regeneration for #11927#11936jordan-wong wants to merge 1 commit into
Conversation
This branch contains the output of an automated integration-authoring pass on `sparkjava-2.3`, produced against the draft skill in #11927. Opened as a draft PR for reviewer reference during discussion of that skill PR; not intended to be merged as-is. Base: master @ cd03735 Target module deleted before the run so the authoring flow had to generate it from scratch (blind test — output has no visibility of the shipping module). Diff scope: only `dd-java-agent/instrumentation/spark/sparkjava-2.3/` plus entries in `metadata/supported-configurations.json`. All other generation artifacts (`.analysis/**`, workflow state) are excluded.
|
❌ New Groovy Files Detected Please avoid introducing new
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 |
Summary
Testing
|
|
🎯 Code Coverage (details) 🔗 Commit SHA: a4c5a09 | Docs | Datadog PR Page | Give us feedback! |
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
|
|
||
| @Override | ||
| public String instrumentedType() { | ||
| return "spark.webserver.JettyHandler"; |
There was a problem hiding this comment.
I see it added span-creating advice for a specific (Spark) handler. This level of detail might not be required depending what spans the framework instrumentation is creating.
Specifically here it's creating a request span from the handler's request context - but the framework instrumentation should already be doing that.
| testImplementation group: 'com.sparkjava', name: 'spark-core', version: '2.4' | ||
|
|
||
| latestDepTestImplementation group: 'com.sparkjava', name: 'spark-core', version: '+' | ||
| latestDepTestImplementation group: 'com.sparkjava', name: 'spark-core', version: '2.3' |
There was a problem hiding this comment.
I'd expect to see 2.+ for the latest test version here
| group = 'com.sparkjava' | ||
| module = 'spark-core' | ||
| versions = "[2.3,)" | ||
| versions = "[2.3,2.4)" |
There was a problem hiding this comment.
The AI has narrowed this down too much - it should be more open
Reference draft for the skill PR #11927. This diff is the output of an automated integration-authoring pass on
sparkjava-2.3against 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.3module 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 @
cd03735159Scope: 15 files, +755/-330 — only inside
dd-java-agent/instrumentation/spark/sparkjava-2.3/and entries inmetadata/supported-configurations.json.Rule adherence — how the output compares to the shipping module
MatcherFilterInstrumentationcallsDECORATE.startSpan(request, parentContext)inside Jetty's activeservlet.requestspan, and instantiates a newSparkJavaDecorator— exactly what this rule was drafted (from @codex on #11708) to prevent. Master's single-class approach only callsHTTP_RESOURCE_DECORATOR.withRoute(activeSpan(), ...).defaultEnabled() = false(sparkjava was intentionally opt-in); dropped the groupDD_TRACE_SPARKJAVA_ENABLEDflag frommetadata/supported-configurations.jsonentirely, silently breaking any customer using it to disable the integration; muzzle narrowed from[2.3,)to[2.3,2.4)super(...)namingsuper("sparkjava", "sparkjava-2.3")where master usessuper("sparkjava", "sparkjava-2.4")(the-2.4reflects the version the code exercises — see thebuild.gradlecomment on master). New instrumentation createdDD_TRACE_SPARKJAVA_2_3_ENABLEDwhere none existed.metadata/supported-configurations.jsonpopulated correctlyDD_TRACE_SPARKJAVA_ENABLEDflag missing (see above)*Advice.javahelperClassNames()completeHelperMethodsanti-pattern absentThread.sleep, no defaultjvmArgs,ForkedTesthas an isolation-reason comment; but embedded server is not astaticfield, and route setup is duplicated acrossSparkJavaTest.groovyandSparkJavaForkedTest.groovyinstead of factored into a baseThe 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.3is under separate open PRs (#11708) with its own review track.