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

Fix SmallRye Fault Tolerance build-time class loading #19609

Merged

Conversation

Ladicek
Copy link
Contributor

@Ladicek Ladicek commented Aug 24, 2021

The Fault Tolerance extension performs discovery at build time.
It finds bean classes that use fault tolerance annotations and
passes that information to runtime (where SmallRye Fault Tolerance
applies runtime configuration). To represent types, SmallRye
Fault Tolerance uses Class objects, and so the discovery process
used to load bean classes from the deployment classloader.

This works fine, unless one of the bean classes is generated
by another Quarkus extension. These generated classes are stored
in memory and the deployment classloader doesn't know about them.
Naturally, attempting to load the class fails and aborts the build.

This commit fixes the problem by not loading the classes at all.
Instead, a class proxy is generated for each class. This still lets
us use Class objects to represent types, but they are never loaded
during build, only at runtime.

The class proxy construct is marked as deprecated, because loading
classes at build time is possible (it wasn't in the past). In this
situation, though, where the class potentially isn't available,
it's a perfect fit.

Fixes #19606.

@Ladicek
Copy link
Contributor Author

Ladicek commented Aug 24, 2021

Third attempt to fix #19606, hopefully this time, it's gonna work :-)

The Fault Tolerance extension performs discovery at build time.
It finds bean classes that use fault tolerance annotations and
passes that information to runtime (where SmallRye Fault Tolerance
applies runtime configuration). To represent types, SmallRye
Fault Tolerance uses `Class` objects, and so the discovery process
used to load bean classes from the deployment classloader.

This works fine, unless one of the bean classes is generated
by another Quarkus extension. These generated classes are stored
in memory and the deployment classloader doesn't know about them.
Naturally, attempting to load the class fails and aborts the build.

This commit fixes the problem by not loading the classes at all.
Instead, a class proxy is generated for each class. This still lets
us use `Class` objects to represent types, but they are never loaded
during build, only at runtime.

The class proxy construct is marked as deprecated, because loading
classes at build time is possible (it wasn't in the past). In this
situation, though, where the class potentially isn't available,
it's a perfect fit.
@Ladicek Ladicek force-pushed the fix-fault-tolerance-buildtime-classloading branch from ed33551 to e5a688f Compare August 24, 2021 09:31
@geoand
Copy link
Contributor

geoand commented Aug 24, 2021

I assume we want this in 2.2 correct? If so, please add the backport label

@Ladicek
Copy link
Contributor Author

Ladicek commented Aug 24, 2021

I'll do everything once I can confirm this works. But I have high hopes :-)

@Ladicek
Copy link
Contributor Author

Ladicek commented Aug 24, 2021

All tests passed in my fork, yay!

@Ladicek Ladicek marked this pull request as ready for review August 24, 2021 13:21
@geoand geoand added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Aug 24, 2021
@Ladicek Ladicek merged commit de32b2e into quarkusio:main Aug 24, 2021
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Aug 24, 2021
@quarkus-bot quarkus-bot bot added this to the 2.3 - main milestone Aug 24, 2021
@Ladicek Ladicek deleted the fix-fault-tolerance-buildtime-classloading branch August 24, 2021 19:46
@gsmet gsmet modified the milestones: 2.3 - main, 2.2.0.Final Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RestClient Reactive + Fault Tolerance doesn't work
3 participants