qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-2051) ensure the expected log4j configuration is used, and check the validity of the Log4J XML configuration file before applying it
Date Sun, 16 Aug 2009 20:43:14 GMT

     [ 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


Mime
View raw message