Skip to content

Introduce feature flag for auto-closing AutoCloseable in Jupiter's ExtensionContext.Store #4434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
4 tasks
marcphilipp opened this issue Mar 28, 2025 · 2 comments · May be fixed by #4452
Open
4 tasks

Introduce feature flag for auto-closing AutoCloseable in Jupiter's ExtensionContext.Store #4434

marcphilipp opened this issue Mar 28, 2025 · 2 comments · May be fixed by #4452

Comments

@marcphilipp
Copy link
Member

marcphilipp commented Mar 28, 2025

Currently, only instances of CloseableResource that are stored in an ExtensionContext.Store are closed automatically when the ExtensionContext is closed. However, items stored in the session-/request-level stores only need to implement AutoCloseable. To address this confusing difference in behavior, we should introduce a configuration parameter that allows to treat AutoCloseable like CloseableResource in Jupiter's stores. It should be "on" by default in 5.13.

Deliverables

  • Introduce configuration parameter for enabling auto-closing AutoCloseable objects (true by default)
  • Deprecate CloseableResource
  • Make CloseableResource extend AutoCloseable so existing implementations would keep working Doesn't work because CloseableResource#close is allowed to throw Throwable, not just Exception
  • Log warning if an object is put into encountered while closing the Store that implements CloseableResource but not AutoCloseable (if the feature is on)
  • Document migration path for external extensions (implement both CloseableResource and AutoCloseable should they need to support pre-5.13 versions)
@YongGoose
Copy link
Contributor

I have knowledge of session/request-level stores, so this issue seemed even more interesting to me. 🙂

I went ahead and did some work on it in my personal repository. After the PR below is merged, I believe it makes sense to continue the work from there, so I branched off from that branch to proceed with the task.

If the JUnit team plans to address this issue, I will focus on other tasks.
However, if there are no plans at the moment, I would like to take a crack at it.

@marcphilipp
Copy link
Member Author

However, if there are no plans at the moment, I would like to take a crack at it.

SGTM! 👍

After the PR below is merged, I believe it makes sense to continue the work from there, so I branched off from that branch to proceed with the task.

I'll do my best to get it merged soon, hopefully this afternoon.

YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 6, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 9, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 9, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 9, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 12, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 12, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 12, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment