Prevent duplicate loading of plugins in PluginLoader

[joschi]

When plugins were available multiple times on the class path or in the plugin directory of Graylog, the PluginLoader used to load identical plugins multiple times. By using a sorted set and a specialized Comparator in PluginLoader we prevent that behaviour.

[kroepke]

Will this always add the classpath plugins before the jar plugins and always load the oldest plugin version?

I think it should be the other way around, allowing jar plugins to overlay classpath one's and later plugin versions to be preferred.

[joschi]

The Plugin interface doesn't require equals and hashcode and if plugin authors don't override those methods, the set could still contain duplicates (i. e. same plugin in different versions) as the default method implementations in Object will be used.

[joschi]

As a matter of fact, the plugins in the classpath will also be contained in the collection returned by loadJarPlugins() because the same classloader is used as parent classloader for the URLClassLoader instances created in that method.

[kroepke]

fair enough, let's address this in a later iteration, then.

[kroepke]

same as above?
why do we need a second set here?

[joschi]

The PluginAdapter class takes care of eliminating duplicate plugins (in different versions) by only taking the unique ID and the name of the plugins into account for equals() and hashcode(). The sorted set can still contain duplicates (as described in #948 (comment)).

[kroepke]

ah, missed that comment.

[kroepke]

I think that a plugin's name is only used for display purposes, right?

If that's true, then I think the name itself should not be used for comparisons, instead we should define what the unique id should look like.
I would say we should advise people to use a package or class name, like the Riemann output plugin does: https://github.com/Graylog2/graylog2-plugin-output-riemann/blob/master/src/main/java/org/graylog2/outputs/riemann/RiemannOutputMetadata.java#L14

[kroepke]

otherwise lgtm 👍