Skip to content
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

Qute CDI integration - named dependent bean is destroyed before it's actually used #24137

Closed
mkouba opened this issue Mar 7, 2022 · 4 comments · Fixed by #24792
Closed

Qute CDI integration - named dependent bean is destroyed before it's actually used #24137

mkouba opened this issue Mar 7, 2022 · 4 comments · Fixed by #24792
Assignees
Labels
area/qute The template engine kind/bug Something isn't working
Milestone

Comments

@mkouba
Copy link
Contributor

mkouba commented Mar 7, 2022

The behavior is not standardized anywhere but it would make sense to follow the CDI rules for EL: https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#dependent_context_ee

NOTE: In this context, "destroyed" means that if a @Dependent bean has a @PreDestroy callback associated then this callback is executed before the bean instance is used e.g. to output a value.

@mkouba mkouba added the kind/bug Something isn't working label Mar 7, 2022
@quarkus-bot quarkus-bot bot added area/arc Issue related to ARC (dependency injection) area/qute The template engine labels Mar 7, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 7, 2022

/cc @manovotn

@mkouba
Copy link
Contributor Author

mkouba commented Apr 4, 2022

We would have to introduce some kind of "expression evaluated callback" in order to implement this correcly.

Alternatively, we could bind a @Dependent bean to the lifecycle of a TemplateInstance or even to a particular rendering operation. In this case we would have to introduce a counterpart to io.quarkus.qute.TemplateInstance.Initializer or similar mechanism.

@mkouba mkouba removed the area/arc Issue related to ARC (dependency injection) label Apr 4, 2022
@mkouba
Copy link
Contributor Author

mkouba commented Apr 5, 2022

Alternatively, we could bind a @dependent bean to the lifecycle of a TemplateInstance.

We couldn't because the lifecycle of a TemplateInstance is not well-defined, in the sense that there is no "destroy" phase/callback.

@mkouba mkouba self-assigned this Apr 5, 2022
@mkouba mkouba added this to the 2.9 - main milestone Apr 5, 2022
mkouba added a commit to mkouba/quarkus that referenced this issue Apr 6, 2022
- dependent beans are now: 1) shared accross all expressions for a single rendering operation, 2) destroyed correctly after
the rendering finished
- resolves quarkusio#24137
mkouba added a commit to mkouba/quarkus that referenced this issue Apr 6, 2022
- dependent beans are now: 1) shared accross all expressions for a single rendering operation, 2) destroyed correctly after
the rendering finished
- resolves quarkusio#24137
@mkouba
Copy link
Contributor Author

mkouba commented Apr 6, 2022

I think that the current behavior makes no sense. However, the CDI rules for EL seem to be quite inefficient. Therefore, in my proposal @Dependent named beans are:

  1. Shared accross all expressions for a single rendering operation,
  2. Destroyed correctly after the rendering finished.

mkouba added a commit to mkouba/quarkus that referenced this issue Apr 6, 2022
- dependent beans are now: 1) shared across all expressions for a single rendering operation, 2) destroyed correctly after
the rendering finished
- resolves quarkusio#24137
mkouba added a commit to mkouba/quarkus that referenced this issue Apr 7, 2022
- dependent beans are now: 1) shared across all expressions for a single rendering operation, 2) destroyed correctly after
the rendering finished
- resolves quarkusio#24137
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/qute The template engine kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant