[
http://jira.codehaus.org/browse/CARGO-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141050#action_141050 ]
Matt Wringe commented on CARGO-585:
-----------------------------------
{quote}
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".
{quote}
OK, that makes sense, if no logging level is specified to just use the copy from the server.
With the latest alpha you can override any file you want on the server, this needs to be documented more. All you have to do is add this to the configuration section of the container:
<configfiles>
<configfile>
<file>${src.dir}/log4j.xml</file>
<todir>conf/log4j.xml</todir> //relative to the cargo home
<configfile>
</configfiles>
Although, it might make sense to add a specific option to pass the log files
{quote}
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.
{quote}
The reason for low, medium and high in cargo is that it makes it easy to specify the level of debugging regardless of the container and regardless of what the container uses for logging.
We need to fix how we are handling debugging in this file
{quote}
3.) Review the log4j.xml files being deployed to make sure they are up to date with the version currently deployed with JBoss.
{quote}
It should be about the same file, I believe it was just renamed to log4j for some reason (and its easy enough to change it back to jboss-log4j.xml). Will change back the file naming to jboss-log4j.xml
{quote}
4.) Make sure Cargo uses the new jboss-log4j.xml files properly.
{quote}
This will be looked into.
> Maven/Cargo/JBoss problem with verbose, unconfigurable logging
> --------------------------------------------------------------
>
> Key: CARGO-585
> URL:
http://jira.codehaus.org/browse/CARGO-585> Project: Cargo
> Issue Type: Bug
> Components: JBoss
> Affects Versions: 1.0, 1.0-maven2
> Environment: Tested with Maven2, JBoss 4,4.2, and 5, Cargo 1.0-Alphas
> Reporter: Jeff Vogelsang
> Attachments: cargo-effective-pom.txt, cargo-generated-log4j.xml, cargo-verbose.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email