ArC - introduce the concept of synthetic injection points

[mkouba]

• a synthetic injection point can be registered by a synthetic bean via BeanConfiguratorBase#addInjectionPoint()
• this injection point is validated at build time and considered when
  detecting unused beans
• at runtime an injected reference is accessible through the SyntheticCreationalContext#getInjectedReference() methods

TODO

• update docs

[mkouba]

CC @geoand @gsmet

[geoand]

As I don't have any context about this, I would like to know what the use case you have in mind is

[mkouba]

As I don't have any context about this, I would like to know what the use case you have in mind is

@geoand Take a look at the second commit (Liquibase extension).

[geoand]

I see, thanks.

Seems like a nice improvement.

[mkouba]

This pull request is also related to #3699. The difference is that synthetic injection points are validated at build time and considered when detecting unused beans. Of course, it's possible to define a synthetic equivalent of @Inject Instance<Object>.

[mkouba]

I found another use case for synthetic injection point while fixing a test failure - the Hibernate ORM extension.

@yrodiere FYI

[Ladicek]

I realized yesterday this is fairly close to what we allow in CDI Build Compatible Extensions (except this is quite a bit better), and that made me think about these interesting test cases that I see are not covered by the tests in this PR:

• synthetic injection point of type InjectionPoint
  • if the synthetic bean is @Dependent
  • if the synthetic bean is not @Dependent (should fail)
• synthetic injection point of type Instance<Object>
  • should disable unused bean removal IIUC, but that's probably sufficiently tested elsewhere
  • lookup of InjectionPoint from that Instance<Object>
    • if the synthetic bean is @Dependent
    • if the synthetic bean is not @Dependent (should fail)
  • lookup of @Dependent bean from the Instance<Object> (should be destroyed when the synthetic bean is destroyed IIUC)
• synthetic injection point that resolves to a @Dependent bean -- test when is the @Dependent bean destroyed

Also, do we want something like this in the synthetic bean disposal function? IIUC, this PR only allows this in the creation function.

[mkouba]

I realized yesterday this is fairly close to what we allow in CDI Build Compatible Extensions (except this is quite a bit better), and that made me think about these interesting test cases that I see are not covered by the tests in this PR:

* synthetic injection point of type `InjectionPoint`

Well, this is something we should probably test.

  * if the synthetic bean is `@Dependent`
  * if the synthetic bean is _not_ `@Dependent` (should fail)

* synthetic injection point of type `Instance<Object>`
  
  * should disable unused bean removal IIUC, but that's probably sufficiently tested elsewhere

This should be tested in the io.quarkus.arc.test.buildextension.beans.SyntheticInjectionPointInstanceTest.

  * lookup of `InjectionPoint` from that `Instance<Object>`

This is rather exotic use case ;-)

    * if the synthetic bean is `@Dependent`
    * if the synthetic bean is _not_ `@Dependent` (should fail)
  * lookup of `@Dependent` bean from the `Instance<Object>` (should be destroyed when the synthetic bean is destroyed IIUC)

This one is interesting.

* synthetic injection point that resolves to a `@Dependent` bean -- test when is the `@Dependent` bean destroyed

A test for synthetic @Dependent bean would be nice.

Also, do we want something like this in the synthetic bean disposal function? IIUC, this PR only allows this in the creation function.

I don't think we want it now. But we could add the support later.

[mkouba]

I found another use case for synthetic injection point while fixing a test failure - the Hibernate ORM extension.

@yrodiere FYI

Hm, there's a problem with the Hibernate Reactive extension - it obviously depends on ORM but some of the dependencies of Session/EntityManager synthetic beans are not registered in the HibernateOrmProcessor.registerBeans(). The tests fail with Unsatisfied dependency for type io.quarkus.hibernate.orm.runtime.TransactionSessions - so it's probably because the Capability.TRANSACTIONS is not present.

I wonder if it actually makes sense to register the beans for Session/EntityManager when using Hibernate Reactive?

@Sanne @DavideD @yrodiere @gsmet WDYT?

[mkouba]

I found another use case for synthetic injection point while fixing a test failure - the Hibernate ORM extension.
@yrodiere FYI

Hm, there's a problem with the Hibernate Reactive extension - it obviously depends on ORM but some of the dependencies of Session/EntityManager synthetic beans are not registered in the HibernateOrmProcessor.registerBeans(). The tests fail with Unsatisfied dependency for type io.quarkus.hibernate.orm.runtime.TransactionSessions - so it's probably because the Capability.TRANSACTIONS is not present.

I wonder if it actually makes sense to register the beans for Session/EntityManager when using Hibernate Reactive?

@Sanne @DavideD @yrodiere @gsmet WDYT?

I've modified the HibernateOrmProcessor to only register a bean for Session/EntityManager if JTA is present.

[Sanne]

I wonder if it actually makes sense to register the beans for Session/EntityManager when using Hibernate Reactive?

No, I don't think people should use the blocking APIs on Hibernate Reactive.

FWIW the fact that the Hibernate Reactive extension is depending on the Hibernate ORM extension was IMO a mistake; it's a fact that the Hibernate Reactive project depends on Hibernate ORM core, but it shouldn't pull in its extension as that expresses a different intent for the user.

[Ladicek]

LGTM, just a few minor comments, feel free to ignore :-)

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[yrodiere]

FWIW the fact that the Hibernate Reactive extension is depending on the Hibernate ORM extension was IMO a mistake; it's a fact that the Hibernate Reactive project depends on Hibernate ORM core, but it shouldn't pull in its extension as that expresses a different intent for the user.

And FTR @mkouba we have an issue about this: #28629