Thank Ralph for the answer related ServiceLoader. I understand your
concerns. A new commons plugin module is in place if we identify the needs
unmet with modern Java. However, the shortcomings you listed are mainly
related to Java 8 and older versions. Thus I would appreciate it if you
could
Right, Provider is a ServiceLoader class, but the same concept can
apply within plugin categories regarding version compatibility or
capability negotiation. Most plugins (besides the "Core" category in
Log4j) are for creating components that can be referenced by name, and
some plugins have their
Matt,
The Logging Provider is not a plugin as it is required way before plugins are
available.
That said, the plugin system certainly could have a way of performing version
checking.
But keep in mind, the versions would be defined by the “owner” of each plugin
category
and not tied to the
Matt,
I don’t see commons-plugins needing a configuration. Remember, there are
several components
in Log4j that don’t use a configuration file. Namely, Lookups,
PatternConverters, KeyProviders,
and Watchers, I view the plugin system as an API that a configuration system
would use to
I used to work on the Jenkins project for a few years, so yes, I'm
fairly familiar with those difficulties. I've also used OSGi in the
past, and I like their approach to semantic versioning and dynamic
"plugin" (well, bundle/component/etc.) lifecycles. I currently work on
the Spinnaker project
No, I think it is a little different, but commons-configuration can be its
dependency.
Gary Gregory 于2022年4月3日周日 18:24写道：
> Should this be in Commons Configuration?
>
> Gary
>
> On Sat, Apr 2, 2022, 15:33 Matt Sicker wrote:
>
> > Hi all, I’ve got a proposal for a new Commons component that I’d
If you really want to start this, it would be useful.
However it would be complicated, very very complicated.
For example, version management.
The plugins have their versions.
And the base program has its version.
And the plugin registration mechanism has its own version.
How to make it work would
>From the Log4j side of things, I didn't exactly overhaul the
configuration parsing or representation of it, so it would depend on
how different that looks in this proposed component. Ideally, though,
a commons-plugins component would replace log4j-plugins and
log4j-plugin-processor along with
I am trying to figure out the input and output of a Commons Plugins
that Log4j would use.
Gary
On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers wrote:
>
> It has been too long since I looked at Commons Configuration for me to answer
> that.
>
> Ralph
>
> > On Apr 3, 2022, at 7:25 PM, Gary Gregory
