Cargo

Maven/Cargo/JBoss problem with verbose, unconfigurable logging

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-maven2, 1.0
  • Fix Version/s: 1.0.3
  • Component/s: JBoss
  • Labels:
    None
  • Environment:
    Tested with Maven2, JBoss 4,4.2, and 5, Cargo 1.0-Alphas
  • Complexity:
    Intermediate
  • Tested on JDKs:
    jdk 1.5, jdk 1.6
  • Number of attachments :
    3

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.

  2. XML File
    cargo-generated-log4j.xml
    08/Jul/08 7:48 AM
    10 kB
    Jeff Vogelsang
  3. Text File
    cargo-effective-pom.txt
    08/Jul/08 7:47 AM
    2 kB
    Jeff Vogelsang

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. CARGO-824 Incorrect log4j logging levels are used in JBoss

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Improvement - An improvement or enhancement to an existing feature or task. CARGO-823 Set properties for JBoss configuration changes instead of using cargo-specific config files

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jeff Vogelsang added a comment -

Example of pom I am using.

Show
Jeff Vogelsang added a comment - Example of pom I am using.
Hide
Permalink
Jeff Vogelsang added a comment -

Cargo-generated log4j.xml file

Show
Jeff Vogelsang added a comment - Cargo-generated log4j.xml file
Hide
Permalink
Jeff Vogelsang added a comment -

Sample verbose log

Show
Jeff Vogelsang added a comment - Sample verbose log
Hide
Permalink
Matt Wringe added a comment -

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".

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

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.

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

3.) Review the log4j.xml files being deployed to make sure they are up to date with the version currently deployed with JBoss.

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

4.) Make sure Cargo uses the new jboss-log4j.xml files properly.

This will be looked into.

Show
Matt Wringe added a comment - 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". 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 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. 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 3.) Review the log4j.xml files being deployed to make sure they are up to date with the version currently deployed with JBoss. 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 4.) Make sure Cargo uses the new jboss-log4j.xml files properly. This will be looked into.
Hide
Permalink
David Santiago Turiņo added a comment -

I have seen it happening with JBoss 4.0.5 GA and the Cargo API also...

Show
David Santiago Turiņo added a comment - I have seen it happening with JBoss 4.0.5 GA and the Cargo API also...
Hide
Permalink
David Santiago Turiņo added a comment -

That <configfiles> seems to be a workaround for this problem, but I don't see how to set it with the current Java Cargo API.

By googling I have just seen that the AbstractStandaloneLocalConfiguration had an internal private Map called configfiles in the rev 1572, but I do not see it exposed with a public method in the javadocs, nor in any ExistingLocalConfiguration related class.

Thanks in advance...

Show
David Santiago Turiņo added a comment - That <configfiles> seems to be a workaround for this problem, but I don't see how to set it with the current Java Cargo API. By googling I have just seen that the AbstractStandaloneLocalConfiguration had an internal private Map called configfiles in the rev 1572, but I do not see it exposed with a public method in the javadocs, nor in any ExistingLocalConfiguration related class. Thanks in advance...
Hide
Permalink
Matt Wringe added a comment -

That <configfiles> seems to be a workaround for this problem, but I don't see how to set it with the current Java Cargo API.

This should be asked on the cargo user mailing list instead of in the bug report. If you have any more questions about it please bring it up there.
[btw see StandaloneLocalConfiguration setConfigFileProperty & setFileProperty]

Show
Matt Wringe added a comment - That <configfiles> seems to be a workaround for this problem, but I don't see how to set it with the current Java Cargo API. This should be asked on the cargo user mailing list instead of in the bug report. If you have any more questions about it please bring it up there. [btw see StandaloneLocalConfiguration setConfigFileProperty & setFileProperty]
Hide
Permalink
Anders Hammar added a comment - - edited

Issue ticket created for problem #2 (CARGO-824).

Show
Anders Hammar added a comment - - edited Issue ticket created for problem #2 ( CARGO-824 ).
Hide
Permalink
Anders Hammar added a comment -

#1 is related to issue CARGO-823

Show
Anders Hammar added a comment - #1 is related to issue CARGO-823
Hide
Permalink
Anders Hammar added a comment -

The original log4j files are now kept (see CARGO-823) and the logging levels haven been fixed (see CARGO-824). Closing as fixed.

Show
Anders Hammar added a comment - The original log4j files are now kept (see CARGO-823 ) and the logging levels haven been fixed (see CARGO-824 ). Closing as fixed.

People

  • Assignee:
    Anders Hammar
    Reporter:
    Jeff Vogelsang
Vote (6)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: