You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org> on 2009/08/16 20:03:14 UTC

[jira] Created: (QPID-2051) ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it

ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it
------------------------------------------------------------------------------------------------------------------------------

                 Key: QPID-2051
                 URL: https://issues.apache.org/jira/browse/QPID-2051
             Project: Qpid
          Issue Type: Improvement
          Components: Java Broker
    Affects Versions: M4, M3, M2.1, 0.5
            Reporter: Robbie Gemmell
            Assignee: Robbie Gemmell
             Fix For: 0.6


The various jars within the Qpid project contain log4.xml and log4j.properties files. The default initialisation procedures of Log4J can pick these up depending on which jars are in the Classpath and apply one of them before the main broker configuration process is undertaken programmaticaly in the Main class, which leads to a mixed configuration. This should be prevented to ensure only the etc/log4j.xml (or other command-line specified file) is the only configuration applied.


The Log4J configuration process proceeds even in the face of malformed XML, or invalid configuration details within valid XML content. The configuration process outputs warnings for malformed XML but does not halt, completing whatever it can but leaving the logging in an uncertain configuration. If an invalid logger level is found, Log4J just silently defaults the Logger (and any inheriting descendants) to DEBUG level.
The broker should validate the XML before applying it, and check that any logger levels are valid Log4J levels before allowing a configuration to be applied. At startup, an invalid XML configuration should resulti in the broker failing to startup. After startup, this should prevent the new configuration being loaded (eg by the XML WatchDog or manually via JMX) over the existing configuration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


[jira] Updated: (QPID-2051) ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it

Posted by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robbie Gemmell updated QPID-2051:
---------------------------------

    Status: Ready To Review  (was: In Progress)

> ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-2051
>                 URL: https://issues.apache.org/jira/browse/QPID-2051
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>    Affects Versions: M2.1, M3, M4, 0.5
>            Reporter: Robbie Gemmell
>            Assignee: Robbie Gemmell
>             Fix For: 0.6
>
>
> The various jars within the Qpid project contain log4.xml and log4j.properties files. The default initialisation procedures of Log4J can pick these up depending on which jars are in the Classpath and apply one of them before the main broker configuration process is undertaken programmaticaly in the Main class, which leads to a mixed configuration. This should be prevented to ensure only the etc/log4j.xml (or other command-line specified file) is the only configuration applied.
> The Log4J configuration process proceeds even in the face of malformed XML, or invalid configuration details within valid XML content. The configuration process outputs warnings for malformed XML but does not halt, completing whatever it can but leaving the logging in an uncertain configuration. If an invalid logger level is found, Log4J just silently defaults the Logger (and any inheriting descendants) to DEBUG level.
> The broker should validate the XML before applying it, and check that any logger levels are valid Log4J levels before allowing a configuration to be applied. At startup, an invalid XML configuration should resulti in the broker failing to startup. After startup, this should prevent the new configuration being loaded (eg by the XML WatchDog or manually via JMX) over the existing configuration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


[jira] Resolved: (QPID-2051) ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it

Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aidan Skinner resolved QPID-2051.
---------------------------------

    Resolution: Fixed

> ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-2051
>                 URL: https://issues.apache.org/jira/browse/QPID-2051
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>    Affects Versions: M2.1, M3, M4, 0.5
>            Reporter: Robbie Gemmell
>            Assignee: Aidan Skinner
>             Fix For: 0.6
>
>
> The various jars within the Qpid project contain log4.xml and log4j.properties files. The default initialisation procedures of Log4J can pick these up depending on which jars are in the Classpath and apply one of them before the main broker configuration process is undertaken programmaticaly in the Main class, which leads to a mixed configuration. This should be prevented to ensure only the etc/log4j.xml (or other command-line specified file) is the only configuration applied.
> The Log4J configuration process proceeds even in the face of malformed XML, or invalid configuration details within valid XML content. The configuration process outputs warnings for malformed XML but does not halt, completing whatever it can but leaving the logging in an uncertain configuration. If an invalid logger level is found, Log4J just silently defaults the Logger (and any inheriting descendants) to DEBUG level.
> The broker should validate the XML before applying it, and check that any logger levels are valid Log4J levels before allowing a configuration to be applied. At startup, an invalid XML configuration should resulti in the broker failing to startup. After startup, this should prevent the new configuration being loaded (eg by the XML WatchDog or manually via JMX) over the existing configuration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


[jira] Assigned: (QPID-2051) ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it

Posted by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/QPID-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robbie Gemmell reassigned QPID-2051:
------------------------------------

    Assignee: Aidan Skinner  (was: Robbie Gemmell)

Hi Aidan can you review this change please, thanks.

> ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-2051
>                 URL: https://issues.apache.org/jira/browse/QPID-2051
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>    Affects Versions: M2.1, M3, M4, 0.5
>            Reporter: Robbie Gemmell
>            Assignee: Aidan Skinner
>             Fix For: 0.6
>
>
> The various jars within the Qpid project contain log4.xml and log4j.properties files. The default initialisation procedures of Log4J can pick these up depending on which jars are in the Classpath and apply one of them before the main broker configuration process is undertaken programmaticaly in the Main class, which leads to a mixed configuration. This should be prevented to ensure only the etc/log4j.xml (or other command-line specified file) is the only configuration applied.
> The Log4J configuration process proceeds even in the face of malformed XML, or invalid configuration details within valid XML content. The configuration process outputs warnings for malformed XML but does not halt, completing whatever it can but leaving the logging in an uncertain configuration. If an invalid logger level is found, Log4J just silently defaults the Logger (and any inheriting descendants) to DEBUG level.
> The broker should validate the XML before applying it, and check that any logger levels are valid Log4J levels before allowing a configuration to be applied. At startup, an invalid XML configuration should resulti in the broker failing to startup. After startup, this should prevent the new configuration being loaded (eg by the XML WatchDog or manually via JMX) over the existing configuration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org