Skip to content
Jose edited this page Oct 16, 2018 · 1 revision

Early this year I skimmed over plugin tools for Java applications. Found some: Atlassian Plugin Framework, jenkins plugins, eclipse framework, NetBeans, pf4j, and osgi (apache aries, gemini, pax, etc)

These were some of our driving goals for plugin stuff in Gluu Casa:

  • Framework should allow easy development and debugging without redeployment of core app
  • Plugins should be vertical – i.e. contain all files (javascript, css and templates, through controllers, to service layer classes) in a self contained manner
  • Framework should register all classes (ideally in the dependency injection container), and (web) resources so they become accessible
  • Plugins should have limited knowledge of what's going on in the rest of the system
  • When a new plugin is onboarded it will fit within current infrastructure
  • A plugin should be set in a state like "disabled" or "out of service" with no disruption of core app
  • A plugin should replaced by other plugin meant to serve the same functionality seamlessly
  • A plugin should be able to expose certain things (eg REST services)
  • In the core app there should be some dashboard to manage plugins

From my reading I identified several approaches for organizing the plugin infrastructure itself, but there is no winner one or rule of thumb. I think it depends on core app nature and goals:

  1. The interface between the plugin and the core is done via messaging (events, subscription, etc.)
  2. Core defines contracts (interfaces) that plugins can implement, at the same time plugins can use APIs the core exposes to do their tasks
  3. Core is agnostic about what a plugin does (it just makes the onboarding but there is few to none core <-> plugin communication)

I dislike the 1st one despite its low coupling, so for Casa, I chose 2+3. Number 3 enables a lot of flexibility and is a safeguard because it's impossible to enumerate all kind of things plugins could do (there is no means to foresee your future requirements beforehand in order to write the interfaces that can be implemented).

For casa I identified just two things I knew I would need for sure:

  • A means to add items to navigational menus. That way as developer, you can take users to pages your plugin itself bundles
  • A means to add a new authentication method. This was to cope for a very specific requirement present in Casa from the very beginning

The more requirements you identify, the more specific code you have to add to the core. This is so because you have to identify at runtime the plugins that currently are implementing a particular interface, and issue appropriate calls. So my advise its to keep those at minimum.

The plugin framework

Frameworks listed above have different learning curves, OSGi being the toughest. If you want to offer 3rd party developers the possibility to write plugins the complexity should be kept as low as possible.

Also I'm fairly sure none of the frameworks above will suffice for the driving goals listed. So I simply chose pf4j and coded custom logic for the more advanced stuff like

Framework should register all classes (ideally in the dependency injection container), and (web) resources so they become accessible In the core app there should be some dashboard to manage plugins

In the end, all goals were fulfiled in Casa.

PF4J is tiny and easy to learn, but it just gives the very basics...

Other possibilities

Casa is small in the sense that the big percentage of its user base has access to a small set of features. For big applications like oxAuth, the approach I followed is probably not the best.

I heard about weld extensions before, actually I found someone leveraging it for plugins in February, but the project is clearly abandoned:

His concepts sound good. It also has JSF involved!. The big con is that adding a plugin requires the app has to be restarted (due to Weld jar scanning).

I recently found a project which may allow to overcome this problem, but requires careful inspection and POC

Casa docs

Here is some useful info about how plugins work in casa. Still incomplete though:

https://gluu.org/docs/casa/3.1.4/developer/