IIUC this will require a dependency on a Java EE jar? For that reason alone, no.
Ralph > On Oct 8, 2019, at 1:23 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > That sounds good Matt, I say go for it. > > Gary > > On Tue, Oct 8, 2019, 16:08 Matt Sicker <boa...@gmail.com> wrote: > >> I've been doing some experiments with the plugin system for 3.x >> lately, and I've recently pushed some changes toward that end. One of >> the insights I gained from it was that some of our plugin annotations >> were redundant (result: @PluginBuilderFactory merged into >> @PluginFactory; @PluginBuilderAttribute deprecated for merging into >> @PluginAttribute). After making those changes, I realized that @Plugin >> and @PluginFactory didn't necessarily need to be separate annotations, >> though I hadn't written any code to try that out yet. However, I did >> realize over time that I was essentially reinventing a mini dependency >> injection framework (hence the historical references to Spring and >> Java EE concepts in the code or comments). In that regard, I >> identified that all the current plugin annotations can be categorized >> as follows: >> >> * @Plugin - essentially identifies an injectable class and its name. >> * @PluginAliases - alternative names for annotated elements >> * @PluginFactory - marks the injection point for a plugin >> * @PluginElement, @PluginNode, @PluginConfiguration - all type-based >> dependency injection corresponding to other plugins (seems to apply >> regardless of the element name as well) >> * @PluginAttribute, @PluginValue, etc. - all name-based configuration >> injection >> >> What I'd like to propose is a vast simplification of this system to >> reuse the javax.inject API [1] since we've already split out >> log4j-plugins into its own dependency. As you can see, it's a fairly >> small package, though we could potentially reuse the API without the >> package names, too. A general conversion of API usage would work like >> such: >> >> * @Plugin name can be replaced by @Named annotation >> * Aliases can still be specified by a separate annotation >> * @PluginElement can be a specific @Scope annotation and generally >> rely on @Inject >> * @PluginFactory can be replaced by @Inject >> * Builder<T> can be replaced by Provider<T> >> * @PluginAttribute can be replaced by @Named @Inject of simple types >> as well as maybe @Qualifier in general >> >> I can work on a PoC for this, though I wanted to see if this idea was >> acceptable here. I don't want to introduce a full blown dependency >> injection framework like Guice/Spring/CDI/etc. since all we need is a >> way to bind configurations to a specific object graph, though the ad >> hoc nature of plugins in the past has made some things harder to keep >> a stable API for, and I think this could help improve that situation. >> >> By going with the standardized annotations, we might also be able to >> take advantage of other tooling for generating static representations >> of a configuration for AOT compilation in microservices or other neat >> things. >> >> [1]: >> https://docs.oracle.com/javaee/7/api/javax/inject/package-summary.html >> >> -- >> Matt Sicker <boa...@gmail.com> >>
