Java SPI Classpath Issue

[troyhofeling]

When deploying an application using this appender we are seeing that the Java Service Provider Interface is used to register the BulkEmitter service. Once an application is deployed, all subsequent deployments fail with this error:

Failed to deploy artifact [xxx-xxxxx-xxxxx]
Caused by: java.util.ServiceConfigurationError: org.appenders.log4j2.elasticsearch.BatchEmitterFactory: Provider org.appenders.log4j2.elasticsearch.jest.BulkEmitterFactory not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:1.8.0_202]
at java.util.ServiceLoader.access$300(ServiceLoader.java:185) ~[?:1.8.0_202]
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) ~[?:1.8.0_202]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) ~[?:1.8.0_202]
at java.util.ServiceLoader$1.next(ServiceLoader.java:480) ~[?:1.8.0_202]
at org.appenders.log4j2.elasticsearch.spi.BatchEmitterServiceProvider.createInstance(BatchEmitterServiceProvider.java:66) ~[?:?]

Is there any recommendation or workaround known for this issue?

Thank You

[rfoltyns]

@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?

[troyhofeling]

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).

[troyhofeling]

Accidentally closed - reopening.

[rfoltyns]

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.

[rfoltyns]

@troyhofeling Any luck fixing your setup?

[rfoltyns]

Closing due to lack of activity.