> On May 30, 2022, at 2:01 AM, Volkan Yazıcı <vol...@yazi.ci> wrote:
>
>> plugin entry interfaces
>
> As Matt has indicated, we indeed need to keep `PluginEntry#interfaces` for
> lazy loading – plus a new `PluginEntry#order` field.
>
>> plugin name vs key
>
> Following up on the responses, I will ask another question: In 3.x, can't
> we deprecate either key or name and stick to only one?
Why? What problem does this solve?
> For instance, I am
> in favor of keeping only `name`, adding a compile-time check to validate
> its content, and cloning it in a `key` field (marked as to-be-removed in
> future) for backward compatibility. The bottom line is, I think if we _can_
> live with one, we should.
This is a typical Plugin definition.
@Plugin(name = "Failover", category = Core.CATEGORY_NAME, elementType =
Appender.ELEMENT_TYPE, printObject = true)
So you want to remove the elementType? Note that “name” is used as the
key to store the plugin into its Category Map. The elementType is usually
what is in the “name" attribute but some Plugins, such as Route, don’t
have an elementType. In those cases the name attribute of the entry is set
to the plugin’s name attribute. PluginRegistry creates a PluginType which
includes the name attribute. This is used all over the place for various
reasons.
So I don’t see how either key or name can be removed since they are used
for completely different purposes.
>
>>> 2. I was expecting `PluginEntry` to be simplified similar to `Plugin`
>>> and only contain a `String key`, `String name`, and `String
> className`.
>>
>> Why would you expect that? All the fields are used by the Plugin system
> and
>> need to be in the plugin metadata to load it. Remember, at this point we
> don’t
>> use the annotations any more.
>>
>>> For
>>> `@Configurable`, we could create a `ConfigurablePlugin` class
> extending
>>> from `Plugin` with extra `elementType`, `printable`, etc. fields.
> Generated
>>> `Log4jPlugins.java` could instantiate either `Plugin` or
>>> `ConfigurablePlugin` depending on the need. In its current state,
> `Plugin`
>>> looks pretty generic, though the rest still resembles the past
> architecture.
>>
>> IMO what you propose just makes things unnecessarily complicated.
>
> Yes, but it completes an important refactoring Matt has been tackling:
> plugin simplification. The frontend (user-facing) part of this story is
> implemented; `@Configurable` and `@Plugin` are two separate concerns.
> Though the backend is still the same: the entire `@Plugin` metadata model
> contains properties of `@Configurable`.
Maybe so, but Matt didn’t actually remove anything. IMO breaking up PluginEntry
wouldn’t solve anything and would, in fact, make the code more complicated.
Ralph
