On 27 Aug 2010, at 12:28, Sorin S. wrote:
Hi,
I am working to extend the operational logging framework to apply to
0-10 code path as well.
In doing so I would like to:
- modify the LogSubject toString method to read toLogString so I can
implement the interface in the 0-10 objects
- log via a generic actor as the current actor model is generating a
log subject which is pre 0-10 specific
- implement the LogSubject interface in 0-10 objects (eg
ServerSession, Subscription_0_10, ServerConnection, etc) in order to
log CON,SUB,CHN type operational log messages, the rest of the
messages remain as they are.
- the logging to be done via a custom instance of the generic actor
using the messages generated from the object itself
- add the necessary to the test suite to address the new changes
Any suggestions,/objections/ideas on the above would be greatly
appreciated
Sorin,
Sounds good. Of course, the nice thing to do after all this is to
remove all the other 'BlahActor' classes and make 0-8/0-9/0-91
logging use the 'GenericActor', now renamed to 'LogActor' simply,
since you won't need a class hierarchy anymore. That way, you can go:
private static final ThreadLocal<LogActor> actor = new
ThreadLocal<LogActor>() {
protected Integer initialValue() {
return new LogActor();
}
};
And get rid of the stack of actors. I think this would work, since
the actor is changed on a per-thread basis, and anywhere you do a
'push' you just do a 'set'. Not sure how you handle the 'pop' though,
would need to think about that?
Another part of the broker that seems superfluous is the
'o.a.q.transport.util.Logger' class, which is simply syntactic sugar
for a suite of 'log.info(String.format(msg, args...))' methods. I
don't remember how prevalent it is, but I'd prefer the logging to use
a consistent API. This means that we should enforce log4j vs. slf4j
in different modules.
The code uses four different logging mechanisms (that I know of).
These are listed below, and some judicious application of 'find/grep/
cut/sort/uniq/tr/sed' to all the Qpid '*.java' source files gives us
the following results. For each logging mechanism, per module, I show
counts of usage (based on imports of a representative class) first
excluding, then including any test classes:
ORG.APACHE.COMMONS.LOGGING.LOG
------------------------------
24 26 management
ORG.APACHE.LOG4J.LOGGER
-----------------------
88 95 broker
6 6 broker-plugins
11 15 client
0 1 common
12 12 integrationtests
11 11 junit-toolkit
1 1 management
10 11 perftests
5 42 systests
1 1 testkit
ORG.APACHE.QPID.TRANSPORT.UTIL.LOGGER
-------------------------------------
16 17 common
33 33 management
1 1 systests
ORG.SLF4J.LOGGER
----------------
6 6 broker
6 6 build
133 139 client
41 49 common
2 2 junit-toolkit
10 10 management
0 84 systests
I admit this methodology can lead to false positives, where classes
are imported and not used, but the results are informative. As you
can see, the 'systests' module uses log4j, slf4j and the Qpid logger,
'common' also uses these three, the 'client' module uses both log4j
and slf4j too. Note that this is not just the tests using a different
logging mechanism, this is actual client and broker code. I recall a
decision being made regarding log mechanism usage for the broker and
client, but can't remember the outcome? There doesn't seem to have
been any progress, regardless, as these numbers show...
Cheers,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7941 197 134 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
