Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[BUG] ServerPlugin implementing no plugin type interface is silently never started or stopped

Đang mở
#398 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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:

  • 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:

  1. A plugin implementing ServerPlugin is registered and gets start() / stop() called, regardless of which type interfaces it implements; or
  2. 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.

Ngôn ngữ chính
Java
Star
227
Fork
81
Merge trung bình
2 ngày 18 giờ
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenIntegrationEngine/engine

Tất cả issue của OpenIntegrationEngine/engine

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.