activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fateev, Maxim" <fat...@amazon.com>
Subject RE: Logging improvement proposal
Date Fri, 13 Apr 2007 17:34:43 GMT
IMHO logging should be enabled/disabled through standard Log4j
mechanisms. I found that it is much easier to switch log level of a
broker then change it on multiple clients. Transport level should log
all messages at trace level, preferably using subject name as a postfix
to the logger name allowing per subject specific configuration. It still
should be possible to override log level for a specific connection using
exising URI based mechanism. 

-----Original Message-----
From: davidmc [mailto:aranmanoth@gmail.com] 
Sent: Friday, April 13, 2007 3:04 AM
To: dev@activemq.apache.org
Subject: Logging improvement proposal


Hello all,

We are interested in enhancing ActiveMQ's current logging functionality,
to help with debugging and profiling. This would be a contribution to
ActiveMQ source code.

Basically we would like to add the following features at the Transport
level:
-Allow different, customizable logging formats. For example, the current
format is human readable but not easily processed by a machine.
-Allow dynamic ON/OFF switching of logging (probably with JMX).

All this of course, without changing the current behavior so that people
who don't need this don't need to worry about anything.

Currently, Transport level logging works with the 'trace' flag. If the
flag
is set to true (for example,       <transportConnector
uri="tcpLog://localhost:61616"/> in activemq.xml), a "TransportLogger"
object gets added into the Transport stack by the corresponding
TransportFactory ).


We propose to enhance the functionality like this:

A. There would be 3 parameters instead of just "trace":

*'loggingEnabled' flag, if set to true, would add a TransportLogger to
the Transport stack. If set to false, the stack bypasses the
TransportLogger, so no logging can take place, regardless of the other
flags. Current 'trace'
flag would stay as an alias for this, so that people who do not care
about this, do not have to change their configuration files or strings.
Defaults to false.

*'initialLogging' flag, if set to true, means that the broker / client
starts outputting to the log file(s) as soon as the TransportLogger is
initialized. If set to false, initially the broker / client doesn't
output anything to the log.
This flag would set the initial value of a boolean who would be
changeable later by JMX.
Defaults to true (if people enable "trace", alias "enableLogging", most
probably they want logging from the beginning. Also to keep current
behavior).

*'logFormat' parameter: this parameter would take values such as
"default"
(current TransportLogger), "detailed", etc. Every value would be mapped
to a different class who would do the actual writing. Maybe
TransportLogger could become an interface that these classes have to
implement, with a TransportLoggerSupport abstract class doing a partial
implementation and that could be extended.
Or maybe TransportLogger could stay as a concrete class and its methods
would call methods from new  classes implementing a "TransportLogWriter"
interface. Defaults to "default" which would use the current
TransportLogger format.

B. As for the dynamic switching with JMX part, there should be some
'global'
boolean value (probably on a per-broker or per-connector basis) used by
all the Loggers to decide if they write to the log or not. Any
suggestions of where to put this boolean value, or where to put a new
Mbean, or how to relay the information to the TransportLogger objects,
are appreciated :)

We initially thought of dynamically removing / adding the Loggers from
the Transport stack, for efficiency when the logging would be disabled.
But this is impossible because the attribute TransportFilter.next is
"final protected", so it cannot be changed. I guess there is a good
reason for this, which is it? :)


We would like to hear your feedback, be it suggestions or criticism,
especially from ActiveMQ developers :) Thanks in advance.

David
--
View this message in context:
http://www.nabble.com/Logging-improvement-proposal-tf3570794s2354.html#a
9976200
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Mime
View raw message