The annotations could index even more info if we wanted. ConverterKeys is another annotation that was introduced due to, uh, I don’t know why actually. Seems like it could use PluginAliases already to define extra converter keys.
Non-core namespace plugins could potentially make use of some of the Configurable metadata, but we don’t have a current use for it, hence the split annotation. — Matt Sicker > On May 30, 2022, at 11:52, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >>> 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 >
