Issue when using Spring Security / AOP proxying with Quasar #108
Comments
|
I've created a minimal example project to demonstrate: https://github.com/imperatorx/quasar-test |
|
Thanks a lot, looking into this shortly. |
|
Here's the reference fork of your example for the following discussion. First of all, after adding Maven plugins for execution and running the app with After a couple of rounds of the above, after which I got every interface method that needed call-site instrumentation in [UPDATED] You control the interface source code though, so an easy workaround is to use the |
circlespainter
changed the title
|
Thank you, using your approach I was able to use spring security using the interface based proxies. After a lot of trial and error, I was able to create a suspendables and suspendable-supers file, that got spring @transactional annotations working also. Unfortunately, I was only able to use the @transactional approach with manual jdbc queries, because using comsat-jooq resulted in weird NullPointerExceptions, but the instrumentation verifier did not warn me about missing anything. The comsat-jooq package was on the classpath, so JOOQ should have been instrumented. I can set up a minimal test project for demonstration int 2-3 days. It seems, that the jooq call for preparedstatement throws this error. I am using a TransactionAwareDataSourceProxy (instrumented via manual config), which is wrapping a FiberDataSource. Manually aquiring a connection from the TransactionAwareDataSourceProxy and creating and running a standard jdbc prepared statement by hand produces no errors, and works as expected. |
|
Thanks, would you mind opening a new distinct issue in Comsat about that? |
|
Sure, I will investigate further and create a new issue with full sample code about the comsat-jooq issue. In the meantime I have found strange behaviour regarding non-interface based proxies. I have updated the repo https://github.com/imperatorx/quasar-test with another proxied bean, but this time the bean implements no interfaces, so instead of a jdk interface proxy, a cglib based class proxy gets created. When I declare "throws Suspendexecution, InterruptedException", the instrumentation fails (because of the proxy catching these exceptions I think), but if I use @Suspendable, the program starts to run, but produces errors, and the instrumentation verifier lists the created cgi proxies' methods as uninstrumented methods. The method org.springframework.cglib.proxy.MethodProxy.invoke (MethodProxy.java:204 bci: 19) ** is listed as uninstrumented, even though I added it to the suspendables file. Is there a way to get non-interface based proxy creation working? |
|
You need to add their methods to And the following to
Also keep in mind that a method marked for instrumentation but which contains no (detected) suspendable call sites won't be instrumented (this happened to me this time because I instrumented the proxies before figuring out they were implementing As an alternative to the simple Mentioning artificial class names is not best but they should typically depend only on the extended class(es) names and on the usage point, so their names should be stable enough for each single use case. Anyway a better (but more time-consuming) integration approach would probably tap into Spring's proxy generation facilities (if possible) and generate the right ones with The reason why |
|
Thanks, the classifier approach is definitely the way to go, since the class names are generated on the fly. I'm going to implement a classifier that checks for superclasses of proxies (I think if there are multiple aop pointcuts then multiple proxy classes are generated and they implement each other in the calling order) and looks for annotations. Hopefully superclasses are always passed to the classifier before subclasses. |
|
I have created a dynamic spring proxy classifier, the example is in this repo: https://github.com/imperatorx/quasar-test-3 The classifier works by scanning classed for a marker annotation. It distinguishes between EnhancerBySpringCGLIB and FastClassBySpringCGLIB types. With this approach, the instrumented proxy gets created, and it works. One strange thing is that these warnings are shown, but only once, not on repeated executions: Will these warnings cause problems, or are these safe to ignore? |
|
These are instrumentation warnings during constructor invocations analysis so they'll be triggered only once per class instrumentation (so typically per application run). If your code works ok they are safe to ignore but nevertheless it can be interesting to know why they are triggered. I'm not very familiar with that instrumentation code portion though; I think @pron knows better. |
|
This happens because the code is not generated by javac. You can safely ignore those messages. |
|
The solution to using class-based proxies to suspendable methods with Quasar is to declare
|
…upport) for interface and abstract methods
|
You can find my changes to enable your app's class-based proxied calls here: https://github.com/circlespainter/comsat-jooq-test |
|
@circlespainter @imperatorx thank you guys , i was faced a spring aop problems, finally solved by add some suspendable method config in suspendables and suspendables-supers files after read https://github.com/circlespainter/comsat-jooq-test code. |
I have tried to implement spring method security, I have used @Suspendable annotations in proxied methods, like the documentation says. When I remove the @PreAuthorize annotation (no proxy is created), I have no errors. When I add the @PreAuthorize annotation, a proxy is created but on fiber blocking, I get a null pointer exception. According to the warnings, the org.springframework.aop.framework.JdkDynamicAopProxy.invoke method is not instrumented, although I have added several methods -including this- to META-INF/suspendables.
The warning:
My suspendables file:
The exception:
Did I miss something, or the instrumentation is not working and fails silently?
The text was updated successfully, but these errors were encountered: