Plugin State Persistence

[jingsewu]

Hello @decebals,

When I see the source codes that if i found you wrote the disable stata into file:

    @Override
    public void disablePlugin(String pluginId) {
        if (isPluginDisabled(pluginId)) {
            // do nothing
            return;
        }
        if (Files.exists(getEnabledFilePath())) {
            enabledPlugins.remove(pluginId);

            try {
                FileUtils.writeLines(enabledPlugins, getEnabledFilePath());
            } catch (IOException e) {
                throw new PluginRuntimeException(e);
            }
        } else {
            disabledPlugins.add(pluginId);

            try {
                FileUtils.writeLines(disabledPlugins, getDisabledFilePath());
            } catch (IOException e) {
                throw new PluginRuntimeException(e);
            }
        }
    }

But why not persist stop state of the plugins?

[decebals]

I don't understand your question.
The code presented by you is DefaultPluginStatusProvider#disablePlugin. DefaultPluginStatusProvider save the plugins status (enable/disable) in files. If someone wants to save these information in other place (database for example), he needs to implement PluginStatusProvider.
The plugin status (enable/disable) concept is different from plugin state (created, resolved, ..).

[jingsewu]

The plugin status (enable/disable) concept is different from plugin state (created, resolved, ..).

Thank you for your reply. However, I have a concern about this approach. Why not persist the other states (created, resolved, etc.) as well?
In some scenarios, if the server restarts, we also need to know whether the plugin was stopped or in another state. Persisting all possible states would provide more comprehensive information, especially after restarts or failures.

[decebals]

Why not persist the other states (created, resolved, etc.) as well?
In some scenarios, if the server restarts, we also need to know whether the plugin was stopped or in another state.

I didn't encounter a such use case. Enable/disable state is important and we want to keep this information (see the plugin system from IDEA IntelliJ). Other plugin states are more dynamic (when we start the plugin system -> move plugin state from one value to other value, step by step; when stopping we do the reverse operations).

If someone wants a such functionality, it's easy to achieve via PluginStateListener.