We're updating the issue view to help you get more done. 

Maven/Cargo/JBoss problem with verbose, unconfigurable logging

Description

Using Cargo / JBoss with the maven2-cargo-plugin causes JBoss instances to emit massive levels of logging. For instance, using a zipinstall deployment with Cargo pulling the standard JBoss 4.0.5GA installation, with any logging setting (low, medium high, none specified) will cause JBoss to emit approximately 800,000 lines of logging during container startup.

I have tested this using JBoss 4.0.5-GA, JBoss 4.2.2-GA, and JBoss 5.0.0-CR1.

I have looked into what is happening and I think it at least partially has something to do with how the Cargo is setting up log4j.xml. What I have noted is this:

1.) There is NO way to configure Cargo using the Maven plugin to just leave the log4j.xml file alone in some container configs (have tried the zip and standalone configs so far). It will always replace whatever log4j.xml you provide with its own interpolated version at runtime. There is no way to intercept or override this. It looks like this happens on start-container, and not during the generation of resources. I think that means there is no way to put the log4j.xml back using other methods since there is no phase to hook to before JBoss starts with the bad log4j

2.) Cargo is setting values for all thresholds in the log4j.xml file to low, medium, or high. The log4j.xml file distributed with any version of JBoss use the normal debug, error, warn, and info levels. It's not clear that JBoss understands what to do with a threshold of "low" in log4j.xml files.

3.) Starting with JBoss 4.2.x, JBoss settings for logging are in jboss-log4j.xml, and are not stored in log4j.xml. This was done (I think) to prevent JBoss' logging settings from interfering with deployed applications that include their own. Cargo should work with this.

Possible solutions?

1.) By default, do not replace the log4j.xml file provided by JBoss. If no logging level is specified in the plugin configuration then leave the log4j.xml file alone and copy the installed version. I am not sure why this is not the default behavior. This one is very important. If I want to provide my own log4j.xml file or jboss-log4j.xml to Cargo, I should be able to do so, and Cargo should not overwrite the provided file. That file is granular and it makes sense to set different logging levels for different categories, rather than setting every category generically to a level like "medium".
2.) Allow passing standard logging levels like info, warn, error, debug, etc... If this is not possible choose a mapping, as in map high to info medium to error, and high to debug, make the mappings known, and write the standard values to the log4j.xml files instead of low, medium, and high.
3.) Review the log4j.xml files being deployed to make sure they are up to date with the version currently deployed with JBoss.
4.) Make sure Cargo uses the new jboss-log4j.xml files properly.

Status

Assignee

Anders Hammar

Reporter

Jeff Vogelsang

Components

Fix versions

Affects versions

1.0

Priority

Major