Context tests and implementation improvement proposals

[PerfectSlayer]

What Does This Do

This PR is a proposal of few refactoring changes:

• Dedicated context listener assert methods:
  • The goal is to have a (small) dedicated API to evaluate context events, and without having to give back the previously asserted event.
  • It allows to tests more nicely and finely the events as we can now easily test for the next event right after a context method call.
  • I did not change the test logic by introducing finer event tests, I only deduplicated events that are previous tests from the past list element check.
  • This should also help when we will refine product / feature integration with the new context API to write more granular tests.
• Introduce context holder swap to deduplicate code
  • Add a common method to deal with the holder swap and listener
  • I expected to be inlined but that would avoid having fixing one part but missing the others
• Introduce event dispatch to deduplicate code
  • Sort of similar approach with event dispatch for listeners
• Add null annotations for context manager implementation
  • Minor change adding @NonNull annotation on ContextManager implementation in core
• Fix variable name following 11763
  • Minor nitpick about variable name following type change

Motivation

Those are proposals. Let me know which one you agree with and want to get merged, and which one should I drop from this branch.

Additional Notes

I planned to push this feedback early but I discovered the issue with code coverage in the meantime.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level (note: the PR still needs to be mergeable, this will only skip the pre-merge build)
  • Get more information in this doc

Jira ticket: [PROJ-IDENT]

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.

[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.86 s	14.74 s	[+0.1%; +1.6%] (maybe worse)
startup:insecure-bank:tracing:Agent	13.66 s	13.70 s	[-0.9%; +0.3%] (no difference)
startup:petclinic:appsec:Agent	16.93 s	16.81 s	[-0.4%; +1.8%] (no difference)
startup:petclinic:iast:Agent	16.98 s	16.94 s	[-0.5%; +1.0%] (no difference)
startup:petclinic:profiling:Agent	16.84 s	16.94 s	[-2.0%; +0.8%] (no difference)
startup:petclinic:sca:Agent	16.92 s	16.75 s	[+0.2%; +1.9%] (maybe worse)
startup:petclinic:tracing:Agent	15.99 s	15.98 s	[-1.1%; +1.2%] (no difference)

Commit: aacfd501 · 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.

[mcculls]

How about calling them beforeSwap and context to match the callers.

Could also trim the comment to:

Suggested change

	* Swaps {@code from} {@link Context} by {@code to} {@link Context} on the given holder, notifying
	* listeners.
	* Swaps {@code beforeSwap} with {@code context} in the given {@link Context} holder, notifying listeners.

Other options include detach and attach etc...

[mcculls]

also should we call the method doSwap to distinguish it from the public method?

[PerfectSlayer]

Done in aacfd50
I can also drop the whole Javadoc as it's internal private method. I was a bit hesitant between dropping it or having a full Javadoc (with all @param). So I ended up with this in between solution with @code which is not the best either 🤷

EDIT:

also should we call the method doSwap to distinguish it from the public method?

This one loaded after the first fix. I dropped the Javadoc comment because it felt explicit enough using the new method name, thanks

[mcculls]

I can see the intent behind the changes - but I'm getting mixed results from ContextManagerBenchmark which I'd like to investigate before approving (basically want to make sure it's just noise and not a real difference.)

Perhaps the test improvements could be separated out into their own PR?

[PerfectSlayer]

Sure, I created #11839 with only the changes from tests, @NonNull and typo. If it gets merged, I will rework this one to excludes the related proposal commits.