What you want to see in next version(s)?

[decebals]

No description provided.

[tylerhawkes]

I'd like to see a maven build plugin so that there isn't so much config that needs to be done to get it to build a zip file just right.

[decebals]

@tylerhawkes
Right now, you can use maven-assembly-plugin (https://github.com/decebals/pf4j/blob/master/demo/plugins/plugin1/pom.xml#L68).
In the past there were some suggestions:
#67 and #170. Maybe we can find an elegant and simple solution. Any contribution in this direction is welcome.

[seziCZ]

Hi @decebals, I am considering PF4j as a plugin framework in one of our projects, requirements of which include the possibility to "hot deploy" new plugins on the fly, without the need for an application to be restarted. Does current version support such a scenario?

[decebals]

@seziCZ
PF4J comes with support (see PluginManager) for load new plugin, stop, start, unload plugin on the fly. If you add a new plugin I think that it's OK. If you want to update a plugin that already run, it's another story and I think that is not easy to achieve (I didn't test this scenario but they are Java classic issues related to ClassLoaders and Classes).

[hxzhao527]

A blameless lifecycle, just like Vue lifecycle
.
I think the plugin lifecycle is the core for PluginManager.

[tylerhawkes]

I'd like to see the annotation processor be able to treat annotations that have Extension on them as if they were an Extension annotation. I have an annotation that I use everywhere and I always have to include Extension as well to get extension discovery. It looks like getSupportedAnnotationTypes() needs some more logic to support this, but I don't know of a good way to do it without the annotation processor being its own module so it can have its own dependencies.

[decebals]

@tylerhawkes

I'd like to see the annotation processor be able to treat annotations that have Extension ...

Can you add more details (examples) because I don't understand.

[eladtamary]

My first thought was to ask for an ability to use the plugins as Spring beans and be able to use @Autowired inside a plugin class.
After doing a quick search I saw that its already done in recent versions.
Just wanted to say thanks!
Elad

[tylerhawkes]

@decebals I have an annotation type that helps define how Jackson should deserialize yaml into an object structure. It is required on every class that implements one of the interfaces that extends ExtensionPoint. I don't have pf4j instantiate objects because users can dynamically configure classes by providing several yaml files that match object structure at run time.

I'd like the interface to look like

@Extension
public @interface JacksonType {
  String[] value();
}

then when I use it on a class like so

@JacksonType({"default", "concrete"})
public class ConcreteClass implements APIInterfaceClass {
  // do stuff
}

I'd like the class ConcreteClass to be treated as if it had the @Extension interface on it since the annotation on the class has been annotated with @Extension.

If you take a look at the project I mentioned earlier, the actual type is @TowerhawkType and it is used a lot of places and always used in conjunction with @Extension which I'd like to only annotation on @TowerhawkType but still have all the classes be included in the extensions.idx file that gets created at compile time through the annotation processor.

[decebals]

@tylerhawkes Thanks for your explanation. I think that I understand what you try to achieve.

[theUPquark]

I'd like a getExtensions(Class type, String ...keywords) method or variation where I could get a list of implementing objects filtered by these keywords. I was thinking these would be added to the Extension annotation itself so that it could be applied to implementations within the application jar.

The idea is I have lists of implemented interfaces in different controllers, and right now I'd have no way of easily narrowing down where I'd want each to go.

[jgomer2001]

Hi @decebals

I'm glad to see your project continues growing...

I would like to have a method beforeDelete at developers' disposal here: https://static.javadoc.io/org.pf4j/pf4j/2.4.0/org/pf4j/Plugin.html

that would be called just before actual deletion takes place. It would be helpful to clean up data your plugin uses for instance, data that is not needed any longer after removal.

Can you update the link here: https://pf4j.org/ref/javadoc.html ? it is pointing to 2.1

[decebals]

@jgomer2001

I'm glad to see your project continues growing...

Thanks! Now is not my project anymore, is an organisation.

I would like to have a method beforeDelete at developers' disposal here...

The Plugin.stop method is for this purpose. Is it not enough?
Before a plugin to be deleted the stop is called.

Can you update the link here: https://pf4j.org/ref/javadoc.html ? it is pointing to 2.1

Thanks! Done.

[jgomer2001]

The Plugin.stop method is for this purpose. Is it not enough?

Well, one might have a plugin stopped for a while, and then starting it. However, when you delete it, it conveys more like "I want to uninstall this and not using it anymore"

[decebals]

@jgomer2001
Done. See #242. I published a new SNAPSHOT that contains the new method.

[WolfgangFahl]

fix https://stackoverflow.com/questions/49759404/gradle-build-compilejava-error-no-access-to-detailed-error

[decebals]

@WolfgangFahl
Please create an issue. Thanks! I saw that you already did it (#243).

[DataWorm]

I'm also very interested in the hot swap feature!
Integrated support to limit plugin permissions (file access etc) with security managers or similar tools would be nice too. For example I would specify a storage directory for each plugin and make sure that each plugin only gets access to that specified directory.

[robzienert]

I'd like to see PF4J loosen its interfaces such that I can provide my own ClassLoader without extending PluginClassLoader.

[decebals]

@robzienert
Thanks for your feedback!

such that I can provide my own ClassLoader without extending PluginClassLoader.

PluginClassLoader is not a class that is part of the general API. It's used only in few places, to implement a base/default behavior:

• pf4j/pf4j/src/main/java/org/pf4j/BasePluginLoader.java

  Line 57 in ee3b5f2

  protected PluginClassLoader createPluginClassLoader(Path pluginPath, PluginDescriptor pluginDescriptor) {

• pf4j/pf4j/src/main/java/org/pf4j/JarPluginLoader.java

  Line 41 in c421a3b

  PluginClassLoader pluginClassLoader = new PluginClassLoader(pluginManager, pluginDescriptor, getClass().getClassLoader());

• pf4j/pf4j/src/main/java/org/pf4j/ServiceProviderExtensionFinder.java

  Line 93 in 01d5926

  Enumeration<URL> urls = ((PluginClassLoader) plugin.getPluginClassLoader()).findResources(getExtensionsResource());

  (this class is less used and I think that the cast in the code is artificially/useless)

I think that is possible to use a custom ClassLoader.

I'd like to see PF4J loosen its interfaces

The interfaces make possible to modify each default behavior of PF4J.

I am open to any recommendations/improvements.

[MunichandraPolanki]

@decebals Thanks for pf4j library , its helpful :)

I have a project with multiple plugins and some of those plugins have multiple extensions. Currently with the 'PluginDependencies' property I can only get the plugin's order of execution . I can use 'Ordinal' among the extensions with in a SINGLE plugin to impose an order of execution among extensions. But , I have a special situation like following .

I have 3 plugins namely PluginA, PluginB and PluginC.

PluginA has 2 extenions PluginAExt1, PluginAExt2
PluginB has 3 extensions PluginBExt1, PluginBExt2, PluginBExt3
PluginC has 2 extensions PluginCExt1,PluginCExt2

Dependency graph b/w plugins as per my requirement is like this . PluginC -> PluginB ->PluginA ,PluginC.
That means I get into cyclic dependency exception.

The actually execution dependency in my use case supposed to have dependency among the extensions.

This is the dependency graph among the extensions I am expecting for my use case which does not function with the current PF4j.

PluginCExt1 -> PluginBExt1 -> PluginAExt1, PluginCExt2.

In a nutshell, I would like to have provision to define the execution sequence of extensions across the plugins.! It seems like , I have to reinvent the wheel using the way pf4j calculates the plugin's dependency graph.

We could also have single extension per plugin, then using just 'PluginDependencies' property we could get the dependency graph provided by PF4J, but that is something we don't want to have as we have strong reasons to include multiple extensions in a single plugin.

Inputs are highly appreciated, thanks!