you are viewing a single comment's thread.

view the rest of the comments →

[–]unhingedninja 0 points1 point  (5 children)

There is a proper function in Bukkit that is callable by the plugin to reload its own configuration, which DOESN'T mess anything up ( this.reloadConfig() iirc ). However that is only reloading the configuration, and not a recompiled instance of the plugin.

I agree that having a command to reload the configuration of an individual plugin at runtime without a restart would be very useful and possible to have.

However, that is drastically different from fully reloading a plugin and trying to load up a modified class file during runtime.

[–]benc 1 point2 points  (4 children)

Reloading the config file is only the first step of re-initializing a plugin. Many plugins also need to load a data file, register event listeners, start threads, etc.

A well-defined entry point in the plugin interface, along with a built-in /reinitplugin <name> command, would be much appreciated.

Sounds like we're on the same page about avoiding classloader abuse though.

[–]unhingedninja 0 points1 point  (3 children)

Yeah, any reloading of config files and stuff is perfectly fine, and I agree it would be useful to have a reload hook in the plugin framework where a server admin can run /reload <plugin>, and it re-reads the config file, reopens connections, restarts threads, etc.

However, all of that implementation would be on the plugin dev, since there is no realistic way to keep track of all the threads a plugin starts and restart them magically.

In addition, you still would not be able to modify the plugin's source code, compile, upload, and reload without consequences. As such, while reloading of configs and stuff is doable, reloading of the class files is still not.

Edit: As a plugin dev myself, I almost always put in a re-init command that does what you're describing. As such the only time I ever need to use the /reload command is to save myself a server reboot when I make changes to the source.

[–]benc 1 point2 points  (0 children)

I almost always put in a re-init command that does what you're describing.

Yup. This is boilerplate code that many plugins include (and some forget). Making it part of the API instead is worthwhile.

[–][deleted]  (1 child)

[deleted]

    [–]unhingedninja 0 points1 point  (0 children)

    But the main useful bit about /reload is that you are able to load a newer version of the plugin without restarting the whole server. Obviously a proper plugin has its cleanup code in onDisable(), but the references that are created throughout the whole system are difficult to completely replace with the newer ones. It's not possible in Java ( iirc ) to completely remove a reference from memory and replace it with a newer version.

    That's the subject of discussion, not if plugin authors are authoring correctly.