My .ear file fails if I try to redeploy it without restarting Wildfly 23.0.2

[Manuel Migueles]

Greetings!

I am experiencing a strange condition when deploying my project on Wildfly 23.0.2. I have already tried to find an answer in all the blogs and pages that I have been able to without success so far. I am writing to this group in the hope that someone knows why this happens:

If I add my .ear from scratch through the HAL Management Console, it displays correctly, but if I try to upload a new version of the .ear file through the "Replace Deployment" option or if I undeploy the project and I try to upload it again without having restarted the wildfly, then the deployment fails and shows me the following message in the log:

Caused by: java.lang.ClassCastException: org.apache.logging.log4j.core.LoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

This message refers to the following line of my code:

LoggerContext context = (LoggerContext) LogManager.getContext (false);

This is impractical for me because it forces me to:

- Undeploy the project in the wildfly.

- Turn off the wildfly.

- Reopen the wildfly.

- Deploy the .ear file again.

All this I have to do, every time I make a change in the project, and I want to deploy the corresponding .ear file generated to the wildfly.

So the question is: Why? Why does it work and it gives me no error message in the log if I add the .ear from scratch, but it doesn't work and it shows me the error message in the log if I want to update the .ear file with the wildfly already up?

Thanks in advance for any assistance. 

[James Perkins]

Are you including log4j2 in your deployment? If so you'll need to exclude either the servers version from your deployment or exclude it from your EAR.

[Manuel Migueles]

Hi! Thank you very much for your answer.

Could you please give me a little more detail about it?

Yes, indeed I am including the log4j jars in my .EAR. What should I do? Get them out of the .EAR?

And what do you mean by "exclude the server's version from your deployment"?

Thanks in advance for any assistance. 

[James Perkins]

WildFly now includes the log4j2 API and an implementation which sends logs to the jboss-logmanager which is configured via the logging subsystem. If you don't want to use your own log4j2 configuration you can simply just remove the api and implementation from your deployment.

If you want to use your own log4j2 configuration, then you need to exclude the org.apache.logging.log4j.api from your deployment with a jboss-deployment-structure.xml, see https://docs.wildfly.org/23/Admin_Guide.html#Logging and note the link to the jboss-deployment-structure.xml is broken and should be https://docs.wildfly.org/23/Developer_Guide.html#jboss-deployment-structure-file.

[Manuel Migueles]

Indeed, after reviewing the documentation you put in your answer, I managed to solve the problem by adding the following code inside the <deployment> tag of the to the jboss-deployment-structure.xml:

<exclude-subsystems>

    <subsystem name="logging"/>

</exclude-subsystems>

<exclusions>

    <module name="org.jboss.logging.jul-to-slf4j-stub"/>

    <module name="org.jboss.logmanager.log4j"/>

    <module name="org.apache.commons.logging"/>

    <module name="org.jboss.logmanager"/>

    <module name="org.jboss.logging"/>

    <module name="org.apache.log4j"/>

    <module name="org.sfl4j.impl"/>

    <module name="org.sfl4j"/>

</exclusions>

Now I can deploy the project and replace the .ear as many times as necessary without having to restart the server.

Thank you very much for your help!

[James Perkins]

You don't need to exclude both the subsystem and the modules. You can do one or the other. The easiest is probably just the subsystem though in case other dependencies are added in newer releases of WildFly.

[Manuel Migueles]

Yes indeed, in more recent tests, I realized that I could get the same result just by excluding the subsystem.

Again, thank you very much for your help!