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 <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> wrote:
> >
> > So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration
> > objects?
> >
> > G
> >
> > On Sun, Apr 3, 2022, 22:18 Ralph Goers <ralph.go...@dslextreme.com> wrote:
> >
> >> If you look at Log4j, we parse the configuration and convert it to a Node
> >> hierarchy.
> >> Variable interpolation occurs as the Nodes are constructed.
> >>
> >> But again, Nothing says a Commons Plugins implementation has to work the
> >> same way.
> >>
> >> Ralph
> >>
> >>> On Apr 3, 2022, at 7:12 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> >>>
> >>> Nice thread :-)
> >>>
> >>> Where does the parsing of configuration files mix in such a stack?
> >>>
> >>> Where does variable interpolation come into play?
> >>>
> >>> Gary
> >>>
> >>> On Sun, Apr 3, 2022, 20:50 Ralph Goers <ralph.go...@dslextreme.com>
> >> wrote:
> >>>
> >>>> Matt J,
> >>>>
> >>>> I fully expect that if commons-plugins came into fruition it would bear
> >> a
> >>>> resemblance
> >>>> to the Log4j plugin system but there would be differences. For example,
> >>>> while Log4j
> >>>> integrates with Spring we don’t currently support having the logging
> >>>> configuration in
> >>>> application.yml. I also suspect it would an almost impossible
> >> abstraction
> >>>> to have the
> >>>> DI system be pluggable, but I could be wrong about that.
> >>>>
> >>>> Of the bulleted items you listed Log4j’s plugin system handles all of
> >> them
> >>>> except that
> >>>> it doesn’t deal with dependencies. Instead, if your plugin is running in
> >>>> an OSGi
> >>>> environment it would be expected that the dependent modules would be
> >>>> available as
> >>>> described by the manifest for the module the plugin is included in.
> >>>>
> >>>> The goals for the log4j-plugins are really pretty simple.
> >>>> * Allow applications to provide flexibility by exposing sets of
> >> pluggable
> >>>> component types.
> >>>> * Allow users to provide their own implementations of the pluggable
> >>>> components that
> >>>> are on an equal footing with the “standard” components.
> >>>>
> >>>> Just by way of example, Apache Flume allows pluggable components such as
> >>>> Sources,
> >>>> Sinks and Channels. Writing a new Sink is fairly straightforward. But it
> >>>> will not be on
> >>>> an equal footing with the Sinks provided by Flume. This is because there
> >>>> is code in
> >>>> Flume that provides an alias (such as “avro” for the AvroSink) so that
> >> the
> >>>> plugin class
> >>>> can be named without having to specify the fully qualified class name.
> >>>> Custom
> >>>> components must be configured using the FQCN.  The Log4j plugin system
> >>>> solves
> >>>> this by requiring every plugin to have a “name” which is then used as
> >> the
> >>>> mechanism
> >>>> to locate it from the configuration.
> >>>>
> >>>> Non-goals would be
> >>>> * It is meant to load plugins, not be a full DI system for every
> >> component.
> >>>> * It leverages standard class loading methodologies, not a new one. i.e.
> >>>> it works with
> >>>> the standard Java class path, module path, or OSGi.
> >>>>
> >>>> Ralph
> >>>>
> >>>>
> >>>>> On Apr 3, 2022, at 8:49 AM, Matt Juntunen <matt.a.juntu...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Hi Matt,
> >>>>>
> >>>>> This is quite timely since I've spent the past week researching
> >>>>> frameworks to modularize a monolithic application at my day job into
> >>>>> separate components/plugins. Everything I've looked at so far is
> >>>>> larger and more complicated than I need (e.g. OSGi, Spring, etc) so I
> >>>>> was seriously considering writing my own, perhaps based on select
> >>>>> components from the Plexus project [1]. I would be interested in this
> >>>>> project if it could do the following:
> >>>>> - provide a standardized plugin packaging format;
> >>>>> - provide standardized configuration mechanisms;
> >>>>> - handle plugin discovery and enumeration;
> >>>>> - handle service discovery, enumeration, and dependency injection;
> >>>>> - handle class loading and resolution of plugin dependencies (e.g. a
> >>>>> plugin that depends on a different version of commons-lang than
> >>>>> another plugin); and
> >>>>> - provide plugin lifecycle methods.
> >>>>>
> >>>>> It would also be great if the project was compatible with different
> >>>>> frameworks. For example, if the dependency injection functionality
> >>>>> could be swapped out for Spring if needed.
> >>>>>
> >>>>> I haven't totally completed my research so I'm not sure if there is
> >>>>> actually an existing framework out there that satisfies the above
> >>>>> requirements. If not, I would be willing to help out to get this
> >>>>> implemented, regardless of whether it ends up in commons or not.
> >>>>>
> >>>>> One more thought: I think it would be equally important (if not more
> >>>>> so) to define the non-goals of this potential project as the goals. Do
> >>>>> you have an idea of what those would be?
> >>>>>
> >>>>> Regards,
> >>>>> Matt J
> >>>>>
> >>>>> [1] https://codehaus-plexus.github.io/
> >>>>>
> >>>>> On Sun, Apr 3, 2022 at 6:24 AM Gary Gregory <garydgreg...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>> Should this be in Commons Configuration?
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> On Sat, Apr 2, 2022, 15:33 Matt Sicker <boa...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Hi all, I’ve got a proposal for a new Commons component that I’d like
> >>>> to
> >>>>>>> get feedback on. Essentially, I’d like to propose the creation of a
> >>>> Commons
> >>>>>>> Plugins component inspired by the plugin system developed for Log4j
> >> 3.x
> >>>>>>> [0]. This library would be a lightweight dependency injection and
> >>>>>>> configuration library where developers create pluggable classes that
> >>>> can be
> >>>>>>> referenced through plugin names via the configuration file (or
> >>>>>>> configuration source in general). In contrast with more typical
> >>>> dependency
> >>>>>>> injection frameworks like Spring and Guice, this library is for
> >>>>>>> applications where pluggable implementations of things is desired.
> >>>>>>> Developing a plugin system on top of DI frameworks is not a very
> >>>>>>> standardized domain, and each project ends up reinventing this from
> >>>> scratch
> >>>>>>> over time.
> >>>>>>>
> >>>>>>> Some existing material on how the Log4j plugin and configuration
> >> system
> >>>>>>> works that I’d adapt from to form the basis for this component
> >> include:
> >>>>>>> -
> >>>>>>>
> >>>>
> >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
> >>>>>>> <
> >>>>>>>
> >>>>
> >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc
> >>>>>>>>
> >>>>>>> -
> >>>>>>>
> >>>>
> >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
> >>>>>>> <
> >>>>>>>
> >>>>
> >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc
> >>>>>>>>
> >>>>>>>
> >>>>>>> The general goal of this library is to make it so that applications
> >> can
> >>>>>>> provide better configuration DSLs for their plugin components. As
> >> both
> >>>> a
> >>>>>>> developer and user, I absolutely despise configuring complex
> >>>> applications
> >>>>>>> with properties files, and YAML variants of properties aren’t that
> >> much
> >>>>>>> better. If there was a common plugin library we could reuse, then
> >>>> perhaps
> >>>>>>> more applications would support a better configuration system. This
> >>>> could
> >>>>>>> also provide a nice place for tooling integration similar to how
> >> JUnit
> >>>> is
> >>>>>>> supported by IDEs and other tools.
> >>>>>>>
> >>>>>>> What do you think? Should this start in the Sandbox? Is anyone
> >>>> interested
> >>>>>>> in working on or using this?
> >>>>>>>
> >>>>>>> [0]:
> >>>> https://github.com/apache/logging-log4j2/tree/master/log4j-plugins <
> >>>>>>> https://github.com/apache/logging-log4j2/tree/master/log4j-plugins>
> >>>>>>>
> >>>>>>> —
> >>>>>>> Matt Sicker
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to