The output of theseīuild steps is some recorded bytecode, using an extension of the ObjectWeb ASM project called Gizmo(ext/gizmo), that is used to actually bootstrap the application at runtime.
Information and can parse any descriptors and read annotations, but should not attempt to load any application classes. These processors have access to Jandex annotation This is the first phase, and is done by the Build Step Processors. The way to port a CDI extension to Quarkus is to rewrite it as a Quarkus extension which will define the various beans at build time (deployment time in extension parlance). Most extension we have seen do not make use of these extreme flexibility capabilities. Too flexible to benefit from the build time boot promoted by Quarkus. The CDI portable extension model is very flexible. These operations should be done at build time and the metamodel be passed to the recorder DSL that will generate classes that will be executed at runtime and boot the framework. Get a framework runningĪ framework at runtime typically reads configuration, scan the classpath and classes for metadata (annotations, getters etc), build a metamodel on top of which it runs, find options via the service loader pattern, prepare invocation calls (reflection), proxy interfaces, etc.
Second best is to write Substrate VM substitutions, which are patches applied during native image compilation. If possible, contribute these patches upstream, not in extensions. It consists of a set of patches to make sure a library runs on GraalVM. This is the less sophisticated extension.
0 kommentar(er)
