Class-loading issue with Java Service Provider Interface and different deployments

[ik81]

Hi,

I am struggling with the use of Java SPI for implementing a plugin-based web app. The plugins - which all implement a common service interface - shall be deployed as separate WAR files (EAR is also ok) on the Wildfly server. The plugins shall then looked up by the core component of the web app using the Java Service Provider interface (i.e. ServiceLoader.load(...)).

The Plugin WAR files are all structured as follows:

WEB-INF\classes\.... the classes of the plugin implementation

WEB-INF\classes\META-INF\services\my.plugin.IPluginFactory.... which references the factory in the classes directory

META-INF\MANIFEST.MF .... containing dependency information as follows

...

Dependencies: deployment.pluginA-0.0.1-SNAPSHOT.war export services, deployment.pluginAPI-0.0.1-SNAPSHOT.war

...

In my opinion this should be sufficient to import the pluginAPI WAR (contains all interface classes that have to be implemented by a plugin) and export its own implementation and service definition. However, when I do a lookup of in my core compoenent's WAR I do not find any implementations of the IPluginFactory interface. The implementation and the service file shall be fine since when I just copy them from the plugin WAR to my core WAR everything works fine. So I think this is just a class-loading issue.

• Exporting the implementation as service shall be sufficient for other modules to find and import it - or do I have to do something else?
• Are there any other means for implementing such a plugin concept on Wildfly where I can add and remove implementations of a certain interface at runtime?
• How can I debug these class loading issues?

Any ideas?

Thanks

[dmlloyd]

I think you have it backwards.  If you want your API WAR to see the plugin WAR service implementation, the API WAR has to have a dependency on the plugin WAR (in addition to the reverse).  That should work although importing WARs as dependencies is probably generally not what one would consider "elegant" (you might want to consider using a JAR instead for the API, and just using Class-Path to reference it from the WARs).

[ik81]

Thanks for your reply. So you mean that I would have to declare both the plugin WARs to export their implementation (and services folder) as well as declare them as (import?) dependency on the WAR which does the service lookup. This sounds very uncomfortable to me because that would render the plugin concept useless. Everytime I deploy a new plugin that implements the interface, I would have to add the dependency in the core and re-deploy the core as well.

I agree that the Dependencies approach does not seem to be elegant. However, I have not found out what the JEE way of realizing such a feature would be. How would you implement such a core / plugin architecture which allows for separate deployments of plugins at runtime?

[klaifer]

It's too late, but can be useful to someone.

I found an article decribing how to do this.

Tutorial SPI (Service Provider Interface) | Code to live. Live to code. (in Portuguese)

Source code on Dropbox - spi-tutorial-src.zip

I used this as reference to do an EAR.