8

I have 7 different WARs deployed to the same WildFly / JBoss server. Each WAR is identical in core design and Log4j configuration. Each WAR generates its own log file via its own individual custom log4j.xml. Each log is written to an individual folders.

1 of the 7 deployed WARs keeps getting the logging hijacked by WildFly's console.log. It will begin writing to its own log for 5-10 lines during initialization, then stop; the rest of the logging will be directed to the console.log.

If I re-install the WAR after this happens, it will write to both its own individual log and the WildFly console.log. If I restart WildFly, it will behave as described previously - begin logging to its own log, then continue on console.log.

The only thing unique about this WAR vs the other 6 is that this project uses JAXB; none of the other WARs use JAXB.

Is there some sort of unknown interaction between JAXB and Log4j and WildFly that might be causing this? I suspect, but cannot yet prove, the hijack is happening after the classes using JAXB are loaded by the ClassLoader.

jboss-7.2.0.Final , jdk-7u80x64, Log4j-1.2.13.jar

JoshDM
  • 4,939
  • 7
  • 43
  • 72
  • Not 100% but sometimes Jboss/wildfly use their own jars instead of those built into the wars/ears so you may need to put the exclusions into the Jboss deployment descriptor xml. – achAmháin Dec 18 '18 at 21:52
  • @achAmháin The other WARs which are not affected by this also use the same Log4j jar; why is this single WAR special? – JoshDM Dec 18 '18 at 21:54
  • I’m not sure. Maybe just try exclude JBoss’ own JAXB modules (assuming there are some) in the deployment descriptor and see if it has any effect. I’ve had issues with log4j in EAP 7 and ended up excluding them and using logging from within each own war file. – achAmháin Dec 18 '18 at 22:01
  • 1
    Are you using a `jboss-deployment-structure.xml` to exclude the logging subsystem or the `org.apache.log4j` module? – James R. Perkins Dec 19 '18 at 18:29
  • @JamesR.Perkins No, I am not. Is that a potential cause of this sort of issue, or is that a cure that I should apply? I suspect you're looking for a cause. – JoshDM Dec 24 '18 at 17:18
  • JAXB itself will likely log with the logging subsystem configuration. However if you're including a log4j configuration your application should be using that configuration. – James R. Perkins Dec 27 '18 at 02:17
  • @JamesR.Perkins that was the solution: Add a jboss-deployment-structure.xml to exclude the org.apache.log4j module. I actually had this exact item configured on a different project and never applied it to this one. Please supply an official answer so I can choose it. – JoshDM Jan 09 '19 at 16:50

2 Answers2

0

You may need to try move the logging.properties file to the WAR/WEB-INF/classes. I guess old Jboss EAP 6.4, There may have been a bug where it fails to look in the WAR/WEB-INF directory.

If that doesn't work you have to turn on trace logging for org.jboss.as.logging which should show the logging.properties file is found in your deployment.

The following CLI command will enable trace logging to see the details of what the logging subsystem is doing.

/subsystem=logging/logger=org.jboss.as.logging:add(level=TRACE)

If you want to see these log messages on the console you'll need to enable trace logging for the console tool.

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=TRACE)

resources:

sect-per-deployment_logging

Logging Configuration

Dilanka M
  • 372
  • 1
  • 5
  • 17
  • This war file has always had the logging properties under the classes folder, and never simply in the web-inf folder. – JoshDM Jan 01 '19 at 16:28
0

Solved by excluding the log4j module from the application via /WEB-INF/jboss-deployment-structure.xml

<jboss-deployment-structure>
    <deployment>
        <exclusions>
            <module name="org.apache.log4j" />
        </exclusions>
    </deployment>
</jboss-deployment-structure>
JoshDM
  • 4,939
  • 7
  • 43
  • 72