[BUG] ServerPlugin implementing no plugin type interface is silently never started or stopped
Les mainteneurs répondent en général sous 2 jours
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 48/100
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Java
- Étoiles
- 227
- Forks
- 81
- Merge moyen
- 3 j 6 h
- PR mergées (30 j)
- 15
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de OpenIntegrationEngine/engine
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
OpenIntegrationEngine/engine#485 ·
Les mainteneurs répondent en général sous 2 jours
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
OpenIntegrationEngine/engine#478 · 1 commentaire ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
OpenIntegrationEngine/engine#355 ·
Les mainteneurs répondent en général sous 2 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
OpenIntegrationEngine/engine#347 ·
Les mainteneurs répondent en général sous 2 jours
-
Fix call-home in test runOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
OpenIntegrationEngine/engine#313 ·
Les mainteneurs répondent en général sous 2 jours
Toutes les issues de OpenIntegrationEngine/engine
Issues similaires
-
[Bug] dubbo.protocol.triple.max-message-size is only read from OS environment variablesPeut-être pris @CCCLL l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
hierynomus/sshj#1070 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
intellij-elixir/intellij-elixir#4492 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 77/100
-
[Server] OpenAPI 3.1 YAML specs generate Object fields: resolveToJSON drops every schema typeOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
quarkiverse/quarkus-openapi-generator#1796 · 1 commentaire ·