The ThreadPool for ConfigurationScheduler is tied to the Configuration. So it
isn’t created until after plugins are loaded (its name should make that
obvious). Also, the number of threads it configures the thread pool for is
determined based on what it finds in the configuration. It is quite pos
Notice that class path scanning only occurs when the following evaluates to
true:
if (builtInPlugins.isEmpty()) {
We encourage the value of this to always be false. I think it would be good to
log an info message indicating that package scanning is taking place and the
application should be cor
> On Mar 8, 2021, at 2:52 PM, Volkan Yazıcı wrote:
>
> Thanks Matt! I have indeed spotted the following line:
>
> // TODO: 2.2+ use this annotation for all @Plugin classes
>
> Right now I am sitting on the fence whether I shall address my issue with
> extending the plugin system or rather im
I am not sure if spawning up and tearing down a new thread pool for each
call would be a good idea.
On Mon, Mar 8, 2021 at 10:46 PM Gary Gregory wrote:
> We do have a thread pool factory that decorates thread names with
> "log4j" IIRC...
>
> On Mon, Mar 8, 2021 at 4:29 PM Volkan Yazıcı
> wrote:
Thanks Matt! I have indeed spotted the following line:
// TODO: 2.2+ use this annotation for all @Plugin classes
Right now I am sitting on the fence whether I shall address my issue with
extending the plugin system or rather implement a MySingletonBeanFactory
interface extending from Comparable a
We do have a thread pool factory that decorates thread names with
"log4j" IIRC...
On Mon, Mar 8, 2021 at 4:29 PM Volkan Yazıcı wrote:
>
> Do we have a Log4j-specific ExecutorService somewhere we can hook into
> PluginManager?
>
> On Mon, Mar 8, 2021 at 10:24 PM Carter Kozak wrote:
>
> > Please d
There's an @Order annotation that's only supported for
ConfigurationFactory plugins that you could extend for arbitrary
plugins perhaps?
On Mon, 8 Mar 2021 at 15:24, Volkan Yazıcı wrote:
>
> I am working on migrating statically bound JsonTemplateLayout resolvers to
> plugins. There certain types
Do we have a Log4j-specific ExecutorService somewhere we can hook into
PluginManager?
On Mon, Mar 8, 2021 at 10:24 PM Carter Kozak wrote:
> Please don't use stream.parallel! It executes tasks on the ForkJoin pool
> which implements work-stealing, and can result in expensive long-running
> operat
I am working on migrating statically bound JsonTemplateLayout resolvers to
plugins. There certain types of resolvers need to have a single
implementation. When a user provides a custom plugin which implements the
same footprint as the singleton one, I need a way to prefer one over
another. I am not
Please don't use stream.parallel! It executes tasks on the ForkJoin pool which
implements work-stealing, and can result in expensive long-running operations
from other components in the system that we don't expect blocking our call
(anything using the fork-join pool, all stream.parallel callers)
PluginManager#collectPlugins() performs quite some package scanning
sequentially. I have the impression that this operation can simply be
parallelized as follows:
Stream
.of(inputs)
.flatMap(input -> Stream
.of(ops)
.map(op -> new Object[]{op, input}))
+1
Verified the snapshots in a few internal projects, as well as code review and
tests on the tag.
Test pass on ubuntu:
$ mvn clean && mvn install
/usr/lib/jvm/java-11-openjdk-amd64/bin/java -version
openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9-Ubuntu-0ubu
Thanks so much Ralph, I can indeed view
https://logging.staged.apache.org/log4j/2.x/manual/json-template-layout.html
https://logging.staged.apache.org/log4j/2.x/manual/layouts.html#JsonTemplateLayout
still misses the correction I have shared, but not a big issue.
I can clean it up later on.
On Sun
13 matches
Mail list logo
