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

CDI: programmatic lookup problem detected - Nayarana - 1.9.0.Final #12896

Closed
juangon opened this issue Oct 23, 2020 · 7 comments · Fixed by #13207
Closed

CDI: programmatic lookup problem detected - Nayarana - 1.9.0.Final #12896

juangon opened this issue Oct 23, 2020 · 7 comments · Fixed by #13207
Labels
area/arc Issue related to ARC (dependency injection) area/narayana Transactions / Narayana kind/bug Something isn't working
Milestone

Comments

@juangon
Copy link

juangon commented Oct 23, 2020

Describe the bug
A warning message is printed when using @Transactional in 1.9.0.Final

Expected behavior
No warning message should show up.

Actual behavior
This message on startup is shown:

CDI: programmatic lookup problem detected
-----------------------------------------
At least one bean matched the required type and qualifiers but was marked as unused and removed during build
Removed beans:
	- PRODUCER_METHOD bean io.quarkus.narayana.jta.runtime.NarayanaJtaProducers#userTransaction() [types=[interface javax.transaction.UserTransaction], qualifiers=[@javax.enterprise.inject.Default(), @javax.enterprise.inject.Any()]]
Required type: interface javax.transaction.UserTransaction
Required qualifiers: [@javax.enterprise.inject.Default()]

To Reproduce

Create any project using @Transactional annotation in some bean. Then just package and startup application.

Configuration

Screenshots

Environment (please complete the following information):

  • Output of uname -a or ver:
  • Output of java -version: JDK 11
  • GraalVM version (if different from Java):
  • Quarkus version or git rev: 1.9.0.Final
  • Build tool (ie. output of mvnw --version or gradlew --version):

Additional context
Related to #12420

@juangon juangon added the kind/bug Something isn't working label Oct 23, 2020
@quarkusbot quarkusbot added the area/arc Issue related to ARC (dependency injection) label Oct 23, 2020
@quarkusbot
Copy link

/cc @mkouba, @manovotn

@mkouba mkouba added the area/narayana Transactions / Narayana label Oct 23, 2020
@manovotn
Copy link
Contributor

There doesn't seem to be a change in the bean declaration (e.g. it was always removeable).
I think it's the added logging in ArC causing this to pop up - what does the application do? Just dynamic Instance<UserTransaction> resolution?

@juangon
Copy link
Author

juangon commented Oct 23, 2020

I am not doing that resolution in code, just using @Transactional, and some other configs. Maybe this line in properties is related, as it may join a transaction?
quarkus.quartz.store-type=jdbc-cmt

@juangon
Copy link
Author

juangon commented Oct 23, 2020

Here is my extension list:
Installed features: [agroal, cdi, flyway, hibernate-orm, hibernate-validator, jdbc-mariadb, mutiny, narayana-jta, rest-client, resteasy, resteasy-jsonb, resteasy-mutiny, scheduler, security, security-jpa, smallrye-context-propagation, smallrye-health, smallrye-jwt, smallrye-openapi, swagger-ui, vertx, vertx-web]

@manovotn
Copy link
Contributor

manovotn commented Oct 23, 2020

This commit expanded logging to include dynamic resolution (Instance) and was part of 1.9. I think this behaviour is "intended" - as in, someone is trying to (presumably dynamically) resolve UserTransaction at runtime but that bean was removed because there was no injection point detected for it at build time.
The final effect should be the same. The caller will get no matching bean for that search (from which they can recover), the only difference should be the additional logging. In which case it's expected behaviour, WDYT @mkouba?

@mkouba
Copy link
Contributor

mkouba commented Oct 23, 2020

Yes, it is expected and the naryana extension should fix the problem; i.e. either make the bean unremovable or don't attempt to use CDI.current().select(UserTransaction.class).

@manovotn
Copy link
Contributor

To sum up, the issue is that Quartz scheduler uses dynamic resolution in the form of Arc.container().instance(UserTransaction.class) which throws this warning but also mangles the scheduler functionality if the bean was removed.
Thanks for the investigation @ochaloup!

@gsmet gsmet added this to the 1.10 - master milestone Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/arc Issue related to ARC (dependency injection) area/narayana Transactions / Narayana kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants