[BUG] ServerPlugin implementing no plugin type interface is silently never started or stopped
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start in DefaultExtensionController.initPlugins(): classes are cast to ServerPlugin then added to serverPlugins only inside instanceof branches for the eight type interfaces. Trace startPlugins(), stopPlugins(), AlertWorker, and DefaultUsageController which all iterate that list. Choose always-register vs reject-with-log, then cover with a plugin that implements ServerPlugin only.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
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:
ServicePluginChannelPluginCodeTemplateServerPluginDataTypeServerPluginResourcePluginTransmissionModeProviderAuthorizationPluginMultiFactorAuthenticationPlugin
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():
AlertWorkercollectsAlertActionAcceptorimplementations from the list.AlertActionAcceptordoes not extendServerPlugin, so it is a marker added onto a plugin class. A plugin implementingServerPluginandAlertActionAcceptor, but none of the eight types above, would never receive alert actions.DefaultUsageControllerreports plugin usage from the same list, so the plugin would be missing from usage statistics.
Expected behavior
Either:
- A plugin implementing
ServerPluginis registered and getsstart()/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.
- 主要语言
- Java
- 星标
- 227
- 派生
- 81
- 平均合并
- 2 天 16 小时
- 30 天内合并 PR
- 12
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
OpenIntegrationEngine/engine 的其他 Issue
-
Outdated GitHub workflow action versions可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
OpenIntegrationEngine/engine#485 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
OpenIntegrationEngine/engine#478 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
OpenIntegrationEngine/engine#355 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
OpenIntegrationEngine/engine#347 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
OpenIntegrationEngine/engine#313 ·
维护者通常 1 天内回复
查看 OpenIntegrationEngine/engine 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
-
account bug communication lecture
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
area/server bug P2
难度 2/5 1-3 小时 新手友好度 68/100
modelcontextprotocol/java-sdk#1196 ·
维护者通常 1 天内回复