Java SPI Classpath Issue about log4j2-elasticsearch HOT 6 CLOSED

@troyhofeling I haven't seen this one before. Looks like a classloader issue.
Could you give me more context, please? Or ideally, an example project that reproduces it?

from log4j2-elasticsearch.

In our use case we run multiple Java applications in a single JVM. Each application has its own Log4J2 instance. The orchestration of applications in managed by a Mulesoft Runtime so I don't think I can provide a sample that would be useful. The service loader fails in java.lang.Class isAssignableFrom method. In this scenario I believe the service is registered using a JVM classloader but the individual applications aren't loading from the same class loader. We observe that once any app registers the BatchEmitter service every new app fails to deploy (log4j2 fails to on startup).

from log4j2-elasticsearch.

Accidentally closed - reopening.

from log4j2-elasticsearch.

You may need to put both log4j2-elasticsearch-jest and log4j2-elasticsearch-core jars in common lib folder (I'm assuming that there's one) and exclude them from your apps. This will ensure that these classes will always be accessible only in your app's parent classloader.

Does it make sense?

Unfortunately, this may lead to more issues with other dependencies (Apache HC, Jackson FasterXML, Disruptor).

Can you define modules in Mulesoft? In a Wildfly-like fashion? This could help you define classloader's content more precisely.

from log4j2-elasticsearch.

@troyhofeling Any luck fixing your setup?

from log4j2-elasticsearch.

Closing due to lack of activity.

from log4j2-elasticsearch.