Skip to content

Plugin management internals#

This page does not cover aspects needed for plugin development. It surveys how Casa handles some aspects of plugin processing under the hood. This information can be useful for developers of Casa or to understand certain behaviors of plugins.

Hot deployment#

Every time a plugin is uploaded, its jar file is copied to /opt/gluu/jetty/casa/plugins. A background task is in place so that when a change in the directory contents is detected, a proper action is triggered, like loading and starting the plugin.

If you manually replace a jar file in the plugins dir, the plugin will be unloaded and then loaded and started. If a file is dropped then the plugin will be stopped and then unloaded.

If a (jar) file is added and there is already another jar implementing the same plugin one of the two files will be removed (not necessarily the older one). Ideally always use the same file name for the same plugin, thus replacing the same file over and over.

Resource extraction and registration#

When a plugin is started, the following occurs internally:

  • All files in the assets directory are extracted into the application's exploded directory inside pl/<plugin-id>
  • A new custom ZK Label Locator is registered. This allows labels defined in jar file labels directory to be recognized by the ZK framework
  • The jar is thoroughly scanned to search for JAX-RS resources annotated with These classes are attached to the RestEasy registry and associated with URLs prefixed by https://<host>/casa/rest/pl/<plugin-id>/
  • A new log4j2 appender is added dynamically, based on the plugin's Logger-Name metadata property

When a plugin is unloaded, the analog steps are performed to de-register all elements added dynamically. Also, plugin assets are removed.

Default (system) extensions#

Casa uses the PF4J concept of default/system extensions to implement the authentication mechanisms supported out of the box. Basically these are extensions that are not tied to a plugin. This approach was employed for developers to have examples to follow when adding authentication mechanisms in their plugins.

Currently, Casa has the following system extensions:

  • for OTP sent via SMS (using Twilio service)
  • for OTP sent via SMS (using SMPP)
  • for U2F security keys
  • for FIDO 2 security keys
  • for OTP tokens (hard and soft)
  • for Super Gluu devices