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 to
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 loaders
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 (or
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 o
