Dealing with new Classes in new Versions

37 views
Skip to first unread message

cove...@ucsc.edu

unread,
Jul 23, 2018, 1:45:22 PM7/23/18
to pf4j
Hi,

We have a command-line tool that uses pf4j to load plugins. We have a script that automatically downloads plugins into plugins directory, then launches our Java JAR, which loads the plugins with pf4j.

The script by default launches the latest version of the tool, but users can specify a specific version of the JAR if they want.

Our issue is that if a new version of the JAR introduces a new interface that a plugin implements, then a user goes back to an older version, we then we get a ClassNotFoundException.

v1 of JAR has interface Foo, and plugin Bar that implements Foo
v2 of JAR has interface Foo2, and plugin Bar2 that implements Foo2

When we run v1, plugin Bar gets copied to plugins directory
We run v2, plugin Bar2 gets copied to plugins directory

When user then goes back to v1, it tries to load all plugins in the plugins directory, and fails with a ClassNotFoundException, because Bar2 implements the Foo2 interface, but v1 does not have that class.

One solution I've thought is to have v2 plugins installed into a separate directory, and then v1 doesn't try to load them. But that's a bit of work to implement, so I was hoping for an easier solution. Is there any way
to have pf4j just ignore ClassNotFoundException? It didn't look like it in the code.

Thanks,

Charles



Decebal Suiu

unread,
Jul 23, 2018, 2:31:51 PM7/23/18
to pf4j
It's not very clear for me what you try to achieve but I think that we can improve this aspect, step by step.
 
The script by default launches the latest version of the tool, but users can specify a specific version of the JAR if they want.
Do you say that your tool is a jar, this tool has a version and each version loads specific plugins version?

Our issue is that if a new version of the JAR introduces a new interface that a plugin implements, then a user goes back to an older version, we then we get a ClassNotFoundException.
If I  understand correct, the extension points interfaces are in your jar/app (core) and your plugins add extensions (implement interfaces) for these extensions points.

You can use PluginManager.getSystemVersion (https://github.com/pf4j/pf4j/blob/master/pf4j/src/main/java/org/pf4j/PluginManager.java#L177) and PluginDescriptor.getRequires(https://github.com/pf4j/pf4j/blob/master/pf4j/src/main/java/org/pf4j/PluginDescriptor.java#L35). In this mode you use only plugins that are complain with app (system) version.

cove...@ucsc.edu

unread,
Jul 23, 2018, 5:17:06 PM7/23/18
to pf4j
Hi,

Yes, we have extension point interfaces defined in the core, and the plugins add extensions/implement interfaces for those extension points.

Yes, the tool is a JAR and has versions. The problem is that it doesn't load specific plugin versions, it tries to load all plugins, and we then run into the issue when the old version of the core tries to load new plugin -- the old core does not have the interface that the new plugin is implementing.

I'll take a look at the methods you mentioned.

Thanks for your help and your quick reply!

Charles

Decebal Suiu

unread,
Jul 24, 2018, 3:25:47 AM7/24/18
to pf4j
The PluginManager.getSystemVersion() method is used with success in UpdateManager from pf4j-update.
I recommend you to use pf4j-update library, if you can.
Reply all
Reply to author
Forward
0 new messages