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

Closed
4 tasks done
marcphilipp opened this issue Mar 28, 2025 · 2 comments · Fixed by #4452
Closed
4 tasks done

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
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 15, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 15, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 15, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 15, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 16, 2025
YongGoose added a commit to YongGoose/junit5 that referenced this issue Apr 18, 2025
marcphilipp added a commit that referenced this issue Apr 28, 2025
By default, instances of `AutoCloseable` are now closed when the `Store`
is closed in addition to instances of `CloseableResource`. The new
`junit.jupiter.extensions.store.close.autocloseable.enabled` config 
param allows reverting to the old behavior.

All core extensions implement both interfaces so they still work when 
the new behavior has been disabled. Extensions implemented in test code 
only implement `AutoCloseable` since they don't need to support that 
mode.

Resolves #4434.

---------

Co-authored-by: Marc Philipp <mail@marcphilipp.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment