wildfly 16, log4j 2.17.0, NoSuchFieldError: EMPTY_BYTE_ARRAY

Asked 24/12, 2021 at 15:59 Answered 21/8, 2023 at 18:41

I get an error during wildfly startup with the following message:

NoSuchFieldError: EMPTY_BYTE_ARRAY

The message also say that this error occurs in undertow deployment. Could anybody give me a hint of what is going on here and how to solve that?

Below is the beginning of the stack trace.

at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:90)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:829)
at [email protected]//org.jboss.threads.JBossThread.run(JBossThread.java:513)

Caused by: java.lang.NoSuchFieldError: EMPTY_BYTE_ARRAY at deployment.taggable-server.war//org.apache.logging.log4j.core.config.ConfigurationSource.(ConfigurationSource.java:56) at deployment.taggable-server.war//org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32) at deployment.taggable-server.war//org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:85) at deployment.taggable-server.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:254) at deployment.taggable-server.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:218) at deployment.taggable-server.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:136) at deployment.taggable-server.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:123) at deployment.taggable-server.war//org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:117) at deployment.taggable-server.war//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:150) at deployment.taggable-server.war//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47) at [email protected]//org.apache.logging.log4j.LogManager.getContext(LogManager.java:196) at [email protected]//org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)

Apathetic answered 24/12, 2021 at 15:59 Comment(5)

[email protected]: you are using log4j-core version 2.17.0, but you didn't upgrade log4j-api to the same version (or you have an older version hanging around). log4j-api has no vulnerabilities, but its version should be synchronized with the version of log4j-core. – Icarian 24/12, 2021 at 16:35

Thanks for the hint, I missed that mismatch. Exclusion of logging API from deployment as suggested by @James fixed my issue. – Apathetic 27/12, 2021 at 16:34

Does this answer your question? Spring boot Log4j2 version 2.15.0 EMPTY_BYTE_ARRAY error in wildfly server – Contemptible 4/1, 2022 at 13:32

@madx answer looks like a solution to their problem. I'll give them a hint. – Apathetic 14/3, 2022 at 9:29

I'm still trying to fix this one out. So Constants is missing EMTPY_BYTE_ARRAY in older versions, yet I've excluded the logging subsystem and log4j 2.17.2 is the only version of log4j files I have. This is quite puzzling. I still say jar hell is worse than DLL hell :-) – Exhale 27/9, 2022 at 17:29

I had the same problem, you can solve it like this:

For a war:

with a jboss-deployment-structure.xml inside src/main/webapp/WEB-INF/ like this:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
     <exclusions>
        <module name="org.apache.logging.log4j.api"/>
    </exclusions>
  </deployment>
</jboss-deployment-structure>

For an ear:

with a jboss-deployment-structure.xml inside src/main/application/META-INF/ like this:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <sub-deployment name="mywar.war">
     <exclusions>
        <module name="org.apache.logging.log4j.api"/>
    </exclusions>
  </sub-deployment>
</jboss-deployment-structure>

Complement answered 27/12, 2021 at 16:10 Comment(3)

I wrote the comment to @James answer with the same solution while you posted this. Thanks. Comments are poorly formatted here. – Apathetic 27/12, 2021 at 16:54

Sorry! I haven't seen the comment! 😅 Thank you for accepting mine. Anyway I think that many will have the same problem in the next few days, as soon as they upgrade log4j dependencies. – Complement 27/12, 2021 at 20:7

I've excluded the entire logging subsystem from JBoss and still getting this error. Honestly I think the better approach if you're not using the built in log4j to exclude the subsystem via <exclude-subsystems> – Exhale 27/9, 2022 at 17:18

You need to exclude the API module from your deployment. Your other option is to use WildFly 26 which include the 2.16 version of the API.

Samhita answered 26/12, 2021 at 15:35 Comment(1)

Thanks for this tip that resolved my issue. In particular I did the following: create a file named jboss-deployment-structure.xml with the content below and put it into src/main/webapp/WEB-INF/jboss-deployment-structure.xml. file content: ```` <jboss-deployment-structure> <deployment> <exclusions> <module name="org.apache.logging.log4j.api"/> </exclusions> </deployment> </jboss-deployment-structure> ```` – Apathetic 27/12, 2021 at 16:46

update the log4j and log4j-api to 2.16.0 version.

if you are using the spring-boot so, add tag in pom.xml

 <properties> 
    <log4j2-version>2.16.0</log4j2-version>
  </properties>

and

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.16.0</version>
        </dependency>

in the pom.xml

Discharge answered 11/1, 2022 at 17:22 Comment(1)

If you're using spring-boot it should pull in log4j-api automatically. Won't hurt to add the dependency, just shouldn't be necessary unless some other dependency is pulling in a different one and then I'd opt to exclude the old version. – Exhale 27/9, 2022 at 17:21

I fixed this issue by updating log4j version to lower version and it worked. Always check whether you have same version of artifacts (log4j-api and log4j-core)

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.17.1</version>
    </dependency>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.17.1</version>
    </dependency>

Clementclementas answered 21/8, 2023 at 18:41 Comment(0)

Recommended topics

Hot tags