You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] ServerPlugin implementing no plugin type interface is silently never started or stopped #398
A server plugin whose class implements ServerPlugin but none of the eight plugin type interfaces is loaded and instantiated, but never registered. As a result its start() and stop() methods are never called, and it is invisible to the other consumers of the plugin list.
I noticed this while working on #120 (PR #397) and am raising it separately rather than changing the behaviour there, since it may well be intentional.
Details
DefaultExtensionController.initPlugins() instantiates each configured server class and casts it to ServerPlugin, then adds it to the serverPlugins list from inside a series of instanceof branches. The types checked are:
ServicePlugin
ChannelPlugin
CodeTemplateServerPlugin
DataTypeServerPlugin
ResourcePlugin
TransmissionModeProvider
AuthorizationPlugin
MultiFactorAuthenticationPlugin
If a plugin class matches none of these, no branch runs, so nothing adds it to serverPlugins. Because startPlugins() and stopPlugins() iterate that list, such a plugin is never started or stopped.
This also affects two other consumers that iterate getServerPlugins():
AlertWorker collects AlertActionAcceptor implementations from the list. AlertActionAcceptor does not extend ServerPlugin, so it is a marker added onto a plugin class. A plugin implementing ServerPlugin and AlertActionAcceptor, but none of the eight types above, would never receive alert actions.
DefaultUsageController reports plugin usage from the same list, so the plugin would be missing from usage statistics.
Expected behavior
Either:
A plugin implementing ServerPlugin is registered and gets start() / stop() called, regardless of which type interfaces it implements; or
If implementing at least one type interface is a deliberate requirement, the plugin is rejected with a clear log message rather than silently loaded and ignored.
Actual behavior
The plugin is instantiated with no error and then silently ignored: never started, never stopped, and absent from AlertWorker and usage statistics.
Additional context
I have not been able to confirm whether any real plugin is shaped this way, so the practical impact may be nil and this could simply be an undocumented constraint. Flagging it because the silent-ignore path makes it awkward to diagnose from the outside.
Relevant code: DefaultExtensionController.initPlugins(), startPlugins(), stopPlugins(), and AlertWorker's constructor.
I agree that a plugin that doesn't fit a constraint should get a warning at runtime.
Personally, I would not accept a PR that radically changed the behavior. However a PR that adds a runtime warning or ideally a compile time error would be reasonable. Just something to warn the plugin developer that their dev process, build process, etc. didn't do the right thing.
I would like to take this one. I will follow the direction from the comment above: keep the current behaviour and add a runtime warning.
What the change does:
In DefaultExtensionController.initPlugins(), after the plugin type checks, it logs a warning when a server class was not registered under any plugin type. The message names the plugin and the class.
It does not change which plugins are started or stopped.
Two unit tests: a class with no plugin type logs the warning and stays unregistered, and a ResourcePlugin logs no warning.
The compile-time check is a bigger design change, so I left it out. I have the patch ready locally and will open a draft PR.
Activity
jonbartels commentedon Aug 3, 2026
This is odd but not blocking.
I agree that a plugin that doesn't fit a constraint should get a warning at runtime.
Personally, I would not accept a PR that radically changed the behavior. However a PR that adds a runtime warning or ideally a compile time error would be reasonable. Just something to warn the plugin developer that their dev process, build process, etc. didn't do the right thing.
Hisham-InfoGleam commentedon Nov 13, 2026
I would like to take this one. I will follow the direction from the comment above: keep the current behaviour and add a runtime warning.
What the change does:
DefaultExtensionController.initPlugins(), after the plugin type checks, it logs a warning when a server class was not registered under any plugin type. The message names the plugin and the class.ResourcePluginlogs no warning.The compile-time check is a bigger design change, so I left it out. I have the patch ready locally and will open a draft PR.