On how casa plugins are

I found a couple of old wiki pages (2018) where some conclusions were drawn with regard to plugins. These are severely biased towards Java

https://github.com/GluuFederation/oxAuth/wiki/Plugin-Architecture

https://github.com/GluuFederation/community-edition-setup/wiki/About-plugins

Details found in the last are still effective in current Casa (4.2.1). In other words:

• A plugin is a self-contained artifact (jar) that packs: UI templates, controllers associated to such templates, resource bundle files, other assets (javascript, css, etc.), and arbitrary Java classes
• A small framework was built on top of the underlying plugin framework (pf4j) that allowed:
  • Extraction of UI templates and assets so they were accessible by web browsing
  • Registering (if any) RestEasy services dynamically
  • Registering i18n stuff
  • Loading the classes found in the jar into a separate class loader (pf4j does it automatically)
  • Mapping the class loader with the mechanism that binds UI templates (zul files) with their respective controllers
• Additional functionalities include managing the lifecycle of plugins. Originally one could load/start/stop/unload a plugin. Later we simplified to load/unload. Unloading implies removal of UI templates, de-registering REST services, etc.

From the functionality perspective:

• We allow to add menu items into several places: The user's home page menu, the admin's console menu, and the top-right menu (where logout is usually placed)
• The items map directly to UI templates bundled in the plugin and they can contain any markup and call any business logic through their respective controllers
• In this case, Casa exercises no control of what the plugins actually does. This is different from the case of plugins that implement authentication methods (the 2nd important use case in the app), where Casa directly calls methods that are expected to be present in the plugin. This is defined by interfaces the plugin must adhere so that it is properly recognized. Here, markup is generated dynamically by Casa using the output gathered from methods calls.

Other remarks:

• Proper docs for plugin development helps a lot. Clear interfaces and java docs have been key as well. Examples too. This has allowed developers other than me to build nice plugins. Even third parties (not Gluuers) have been able to code plugins with minimal-to-zero assistance
• Initially I considered that adding and removing plugins on the fly (no restarts required) was essential. But it turned out not to be that way. In the end it was a hard-to-achieve goal due to JVM's nature.
• Casa has only 2 kind of users (admin/non-admin) so access control was not difficult to implement. In other scenarios where more roles are present, this requires a lot more consideration in the design.