flozano commented on issue #5925: URL: https://github.com/apache/incubator-kie-drools/issues/5925#issuecomment-2107137226
Thanks for answering! > Is there any reason why you're keeping that $asset inside the condition? Does it change anything if you remove it (I don't expect so, but just in case). I'm keeping because the original DRL had it and I wanted to reproduce exactly - but no, it doesn't change anything. I mentioned in: > (I understand $asset inside the condition is redundant). > If the executable model generator can access the runtime classes generated by byte-buddy and introspect them during the code generation phase I believe that there shouldn't be any problem. I believe so too. I use the correct strategy in byte-buddy (`ClassLoadingStrategy.Default.CHILD_FIRST_PERSISTENT`) and expose the right class-loader to drools... so everything is there for drools to access. ### update I just reproduced it, you can find the failing version here: https://github.com/flozano/drools-issues/blob/main/src/test/java/drools/issues/DynamicClassTest.java The changes to reproduce: After properly subclassing in byte-buddy with the generic type descriptor instead of the raw Vehicle class, and using the property getter defined in the parent item (`motor` instead of `engine`), I expected to find same issue as in #5932 (https://issues.redhat.com/browse/DROOLS-7197), but I didn't, I reproduced this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
