I believe it would be a great proof of the whole concept if the DI system
could be plugged into the new commons plugin system using the SPI commons
plugin provides for plugins.
On Thu, Apr 14, 2022 at 8:00 PM Matt Sicker wrote:
> Yes, at this point, it would help to see what aspects of this
Yes, at this point, it would help to see what aspects of this would be
useful or welcomed as a library. In the meantime, I've been asked if I
could port the log4j DI system back to 2.x, so I may end up working on
that in the near term and defer any work to extract code to Commons
until we have a
It sounds like embedded in this discussion are some use cases / requirements.
Would quantifying these some with a high level list of features that this
plugin architecture is to provide?
What would the basic functionality and/or interfaces be…something like:
- Register Plugin/Services
-
Users should be required to do as little as possible to adapt the
plugin system to the environment it is running in*but plugins shouldn’t know or
care anything about how they are located and loaded.* Plugins are also to the
application or framework that will be using them. They essentially
Le mar. 12 avr. 2022 à 21:31, Ralph Goers a
écrit :
>
>
> > On Apr 12, 2022, at 6:56 PM, Thomas wrote:
> >
> >
> > On 11.04.2022 00:00, Ralph Goers wrote:
> >> See below
> >>
> >>> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
> >>>
> >>> Thanks Ralph for the detailed explanation. I
> On Apr 12, 2022, at 6:56 PM, Thomas wrote:
>
>
> On 11.04.2022 00:00, Ralph Goers wrote:
>> See below
>>
>>> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>>>
>>> Thanks Ralph for the detailed explanation. I appreciate it and now I see
>>> the points.
>> I’ve removed the parts that I
On 11.04.2022 00:00, Ralph Goers wrote:
See below
On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
Thanks Ralph for the detailed explanation. I appreciate it and now I see
the points.
I’ve removed the parts that I don’t think need any more discussion.
- How will it be a “plugin" project
Start it here, if it fails, we'll all learn something I am sure.
Gary
On Tue, Apr 12, 2022, 08:53 Gilles Sadowski wrote:
> Le mar. 12 avr. 2022 à 13:23, Gary Gregory a
> écrit :
> >
> > Commons Component can and do depend on other runtime libraries, for
> > example, VFS, Configuration, JCS,
Hi Matt,
That's normal thinking IMO not devil's advocacy :-) The JDK provides a bare
bones extension mechanism in the service loader but that's not enough for a
real plugin system.
Gary
On Tue, Apr 12, 2022, 11:30 Matt Benson wrote:
> Devil's advocate thought: given that Commons, while not
Devil's advocate thought: given that Commons, while not officially limited
to such, has heretofore concentrated on the Java ecosystem; as the core JDK
evolves, matures and provides more and more functionality out of the box,
possibly Commons components would have to increase in complexity to be
Le mar. 12 avr. 2022 à 13:23, Gary Gregory a écrit :
>
> Commons Component can and do depend on other runtime libraries, for
> example, VFS, Configuration, JCS, and so on. There are libraries that are
> naturally lower level where we do want to keep zero depencies like IO and
> Lang. If an app
Commons Component can and do depend on other runtime libraries, for
example, VFS, Configuration, JCS, and so on. There are libraries that are
naturally lower level where we do want to keep zero depencies like IO and
Lang. If an app has a plugin system it seems evident to me that it would be
the
Hello.
Le mar. 12 avr. 2022 à 08:58, Romain Manni-Bucau
a écrit :
>
> Sounds like https://svn.apache.org/repos/asf/commons/sandbox/ can be a
> ready to start place even if I still think incubator is the real place for
> such a project since it will quickly overpass commons standard case with a
>
osystem/platform normally.
> but I
> > > could be wrong.
> > >
> > > Btw: Commons VFS has a plug-in system, mostly for providers.
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
> > >
atform normally. but I
> > could be wrong.
> >
> > Btw: Commons VFS has a plug-in system, mostly for providers.
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > Von: Ralph Goers
> &g
; --
> http://bernd.eckenfels.net
>
> Von: Ralph Goers
> Gesendet: Monday, April 11, 2022 12:00:12 AM
> An: Commons Developers List
> Betreff: Re: New component proposal: commons-plugins
>
> See below
>
> > On Apr 8, 2022, at 9:23 AM, Peter Verhas wrot
Von: Ralph Goers
Gesendet: Monday, April 11, 2022 12:00:12 AM
An: Commons Developers List
Betreff: Re: New component proposal: commons-plugins
See below
> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>
> Thanks Ralph for the detailed explanation. I appreciate it and
See below
> On Apr 8, 2022, at 9:23 AM, Peter Verhas wrote:
>
> Thanks Ralph for the detailed explanation. I appreciate it and now I see
> the points.
I’ve removed the parts that I don’t think need any more discussion.
> - How will it be a “plugin" project and not another dependency injection
Le ven. 8 avr. 2022 à 19:28, Matt Sicker a écrit :
> One iteration of the plugin system was based on Weld and OpenWebBeans,
> but the CDI API is far too verbose for a use case where I didn't have
> a need to integrate with a decade worth of legacy Java EE APIs (no
> JNDI, no JPA, no EJB, no
One iteration of the plugin system was based on Weld and OpenWebBeans,
but the CDI API is far too verbose for a use case where I didn't have
a need to integrate with a decade worth of legacy Java EE APIs (no
JNDI, no JPA, no EJB, no Resource(s) annotations, none of the
DI-alternatives leading up
Le ven. 8 avr. 2022 à 18:50, Matt Sicker a écrit :
> I suspect at this point that most of the remaining slowness in startup
> on Log4j is related to code that _doesn't_ use plugins. There are some
> strategies that configure on startup in log4j-api based on system
> properties and service
I suspect at this point that most of the remaining slowness in startup
on Log4j is related to code that _doesn't_ use plugins. There are some
strategies that configure on startup in log4j-api based on system
properties and service loaders which are provided for improved
steady-state performance
Guess that theorically there is room for a new generic plugin system but I
would mention a few points:
1. log4j one is not yet a good *generic* one for multiple reasons but the
biggest blocker for me is that it is slow (slower than a plain IoC as of
today, even dropping some legacy parts) - there
Thanks Ralph for the detailed explanation. I appreciate it and now I see
the points.
I have never experienced an application where class loading time was an
issue, and I understand that it can really be.
I have never experienced a setup where there were a lot of "plugin" classes
on the classpath
One of the issues I've found with loading classes eagerly is that many
ClassLoader implementations rely on fairly broad locks. Deferred class
loading can avoid some of this lock contention.
On Thu, Apr 7, 2022 at 12:57 PM Ralph Goers wrote:
>
>
>
> > On Apr 7, 2022, at 2:52 AM, Peter Verhas
> On Apr 7, 2022, at 2:52 AM, Peter Verhas wrote:
>
>
>> I would suggest that before responding to this email that
>> you go look at how log4j-plugins is implemented in the master branch.
>>
>
> Sure, if you propose to create a commons-plugin library that is an extract
> of the plugin
Le jeu. 7 avr. 2022 à 14:34, Gary Gregory a écrit :
>
> A slight tangent: a smaller simpler component idea? The log4j variable
> interpolation, the ${lookup:variable} type of logic is in many places:
> deprecated in Commons Lang, now in Commons Text, also implemented in
> Commons Configuration.
A slight tangent: a smaller simpler component idea? The log4j variable
interpolation, the ${lookup:variable} type of logic is in many places:
deprecated in Commons Lang, now in Commons Text, also implemented in
Commons Configuration. We could bring in the Log4j version, now safer than
other
>
> > The plugin system is design to convert configuration data into
> instantiated objects.
>
For me that very much reads a dependency injection framework.
--
Peter Verhas
pe...@verhas.com
t: +41791542095
skype: verhas
> If I had known this was going to turn into a debate I wouldn’t have
> responded to the
> question. But it seems either my response wasn’t clear, you did not
> understand
> what I wrote, or you have some preconceived notion as to why anything
> beyond
> ServiceLoader is needed.
I believe that a
Generally speaking it sounds like there's at least enough interest to
create a repo and start playing. Only recently I could personally have used
a working version of something like this. No guarantees but I'd like to
help if it works out that way, for whatever that's worth.
Matt
On Sat, Apr 2,
Le 04/04/2022 à 02:27, Ralph Goers a écrit :
I don’t think so. Commons Configuration (which I was working actively on when
I started writing Log4j 2) is designed to provide access to the configuration
data.
The plugin system is design to convert configuration data into instantiated
objects.
I
If I had known this was going to turn into a debate I wouldn’t have responded
to the
question. But it seems either my response wasn’t clear, you did not understand
what I wrote, or you have some preconceived notion as to why anything beyond
ServiceLoader is needed. I would suggest that before
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
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 wrote:
>
> So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration
> objects?
>
> G
>
> On Sun, Apr 3, 2022, 22:18 Ralph Goers wrote:
>
Perhaps? I’d have to investigate how commons configuration works to be sure.
And thanks, Ralph, for answering the questions here. I’ll write up a more
detailed proposal we can discuss.
—
Matt Sicker
> On Apr 3, 2022, at 21:25, Gary Gregory wrote:
>
> So in a Commons centric fantasy, Log4j
So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration
objects?
G
On Sun, Apr 3, 2022, 22:18 Ralph Goers 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
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 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 wrote:
> Matt J,
>
> I fully expect that if commons-plugins came into fruition it would bear a
> resemblance
> to
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
I don’t think so. Commons Configuration (which I was working actively on when
I started writing Log4j 2) is designed to provide access to the configuration
data.
The plugin system is design to convert configuration data into instantiated
objects.
I could easily see Commons Configuration
ServliceLoader is used to locate plugins but what is loaded by ServiceLoader
are not plugins.
Log4j Plugins are categorized into different groupings, primarily by where and
how the plugins
are used. For example, PatternConverters used by the PatternLayout are
separate from
Appenders, Filters
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
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 like to
> get feedback on. Essentially, I’d like to propose the creation of a Commons
> Plugins component inspired by the plugin system
What is the feature not provided by Service Loader?
On Sat 2. Apr 2022 at 21:33, Matt Sicker 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
53 matches
Mail list logo
