Some suggestions on MybatisPlusPlugin

[andresluuk]

Hi Looked at the code. Why do you need the markeFile-s? I would suggest doing it without them. checkDependencies is called for each classloader created by the JVM, so even some temp classloaders. if checkDependencies returns true on a classloader then plugins preinit is run on that classloader. I would suggest replacing it with just: public boolean checkDependencies(ClassLoader classLoader, ClassResourceSource classResourceSource) { return classResourceSource.getClassResource("com.baomidou.mybatisplus.core.MybatisConfiguration") != null; } now remove all the marker file stuff from the plugin. The issue StrictMapCBP was that it was applied multiple times? In that case replace it with: integration.addIntegrationProcessor("com.baomidou.mybatisplus.core.MybatisConfiguration$StrictMap", new StrictMapCBP().withDuplicatePatchingProtection()); This method was added in a newer API version or you can add marker field with known name into the StrickMap and check for if the marker field is missing before processing inside the CBP. or actually I think it would be ok just to add the classloader there: integration.addIntegrationProcessor(classLoader, "com.baomidou.mybatisplus.core.MybatisConfiguration$StrictMap", new StrictMapCBP()); then extra magic should not be needed.

Some notes: CBPs added by addIntegrationProcessor only apply if the mentioned class is loaded, so if the class does not exits, then the CBP just does not apply and does not cause any issues. It is better to add addIntegrationProcessor with a classloader if possible.

[SweetInk]

@andresluuk Thanks your suggestion. It's really don't need to add extra magic. I refer to most of the code for this plugin from mybatis-jr-plugin-*.jar, and there is no better reference. By the way, is there a better way to debug my plugin? every time I change the plugin code, I need to use the build tool: mvn install, and then add the VM parameter -Drebel.plugins=myplugin.jar to my demo project to start. This step is very cumbersome.

[andresluuk]

Yes, we don't have very good public example plugins so decompiling is the best way to get some pointers. And for some mybatis extension the mybatis plugin as an example makes sense.

But for debugging the plugin. The only way to test it is to build it and then run the application. The main reason is that any change you make to the CBP is applied when the target class is loaded, and usually it is done only once per application run. We have the same workflow when we rebuild the plugin with "mvn package" and restart the application to start with the update plugin version. In case you have the plugin version in the final jar name, I would suggest removing it, so you don't have to change the plugin reference in the VM parameter after a small version number pump. Now about the VM parameters. You can add the same argument also into jrebel.properties (Some references: https://manuals.jrebel.com/jrebel/misc/agentsettings.html) because the .jrebel folder is picked automatically by jrebel you actually don't need to add the extra "rebel.*" arguments into the command line. Also because you are developing the plugin add the argument also just in case: "rebel.cbp_cache=false" As the name suggest it disables some caches that might be in you way when changing the CBPs.