Replies: 3 comments
-
I should note, if I remove the abstract method, and make the bean "eligible" it works just fine, and the bytecode gets swapped out as intended, with the bean running the modified bytecode. Ideally, I'd need a way to tell CDI to "bypass" the verification it does on that bean, and, by the time the bean actually gets created the bytecode was long swapped. |
Beta Was this translation helpful? Give feedback.
-
I have found a solution, but it is absolutely horrific:
Would there be some build items I could hook into to get after Annotation processing (as I need the annotation to know which classes need modifications) but before the flags for all classes are published in the Jandex index. |
Beta Was this translation helpful? Give feedback.
-
I've been moving forward with the Jandex index solution, but I was curious if it would be possible to do the same thing without lying to the index. |
Beta Was this translation helpful? Give feedback.
-
Hello!
I'm having a problem while building a Quarkus extension. To provide a bit of context: I am building an extension for RPC over the SignalR protocol.
The desired experience is as follows:
Then, inside of the extension I have (approximately this code)
Essentially, the problem I'm having is, the initial bean definition is an abstract class, which makes it ineligible to be a bean, however, after bytecode modification, the is just fine to be used as a bean (as the abstract modifier is removed and the method is replaced with a call to something else)
Triggering AdditionalBeanBuildItem or BeanDefiningAnnotationBuildItem does not seem to help.
What's weird is that for a while the code worked just fine, but I assume further modifications to it slightly altered the build steps, which seems to have broken it.
How would I go about fixing something like this?
For a more expansive codebase: Here!
Beta Was this translation helpful? Give feedback.
All reactions