Hi Andrew, Thanks for your mail, I really appreciate your insight. Will try and make it work on 0-10 in the first step with the GenericActor, then will be more than happy to implement your suggestions. If anyone has any objections to this plan, I would be more than happy to learn about them.
Cheers, Sorin On Fri, Aug 27, 2010 at 10:03 PM, Andrew Kennedy <[email protected]> wrote: > 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] > > -- Sorin S --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
