On 5 June 2013 13:00, Rafael Schloming <[email protected]> wrote: > On the logging topic I think the JMS client (or any project really) should > actually have an internal logging interface that wraps what it actually > uses for logging. I've done this in the past a lot and found it very useful > for a number of reasons. For one thing the internal interface can actually > reflect and enforce the logging categories that are specific to the project > and also introduce a granularity of domain specific control that might not > be available through generic loggers, e.g. toggling per connection, etc. > This also has the significant benefit that any external logging dependency > is limited to a single place in the code and therefore trivial to swap out > with JDK logging or a println or whatever logging library you want. > > I agree, there's really a couple of things wrong with the way most Java libraries do logging... Firstly they tend to confuse operational logging with debug/tracing statements that are useful for developers. Examples in log4j and java.logging where the logging "channel" used is the class name have encouraged this practice, but this seems entirely inappropriate to me. Logging intended for the end user is essentially part of the public API of your library/application. By tieing the logging to the class/package hierarchy you are essentially setting that organization in stone. Even if that is not objectionable to you, it seems entirely inappropriate to expect the end user to understand the static properties of your library/application in order to get useful operational logging about the dynamic properties of the running system. This is my second big issue with logging in the way that it is currently done... loggers tend to be instantiated as static for a given class meaning that (to illustrate Rafi's example) if you want to turn on detailed logging for a particular connection you actually have to turn on logging for *all* connections and then work out which lines are actually of interest. This is particularly annoying in libraries that may be widely used since more than one dependency of your application may in turn depend on the same library.
> I think this approach is probably where we will end up going with proton > with the further step of having the facade actually wrap a configurable > logging callback so we don't need to build in any logging dependency at all > and it becomes easy to integrate the engine's logging with the logging of > its embedding application. > > Yes - I would like to get that work started in Proton ASAP so that we can build on it for the JMS client which uses Proton. As above, I think that logging forms part of the Public API so ideally all implementations of the Proton Engine should aim to generate logs in an identical (or near identical) manner. -- Rob > --Rafael > > > > On Wed, Jun 5, 2013 at 5:53 AM, Robbie Gemmell <[email protected] > >wrote: > > > For TODOs, I usually just consider them all roughly equally (in that > there > > should be a comment saying what needs changed and why) without any > special > > classification. I tend to closely examine all my changes prior to commit > so > > if I mean to change something I have added a TODO for before commiting > then > > I probably would have, so I'm not sure I personally see much specific > value > > in TODO-SVN. For TODO-RELEASE, that seems like more of a JIRA thing for > me; > > either we think the JIRA being worked on isn't finished and would comment > > on it to say there was something specific needing done to allow > completing > > it, or we think it is done but there is need of a new separate JIRA > > blocking the release. > > > > I would tend to mostly echo the previous comments on the toString() etc > > stuff. > > > > Robbie > > > > On 4 June 2013 16:55, Phil Harvey <[email protected]> wrote: > > > > > Given that the AMQP 1.0 JMS Client sub-project is starting from a clean > > > slate, this is an opportunity to define some Java coding standards that > > are > > > somewhat tighter than our existing ones [1]. I've therefore created a > > wiki > > > page for supplementary standards [2] that only apply to this project. > > > > > > I realise I am laying myself open to accusations of being overly > > > prescriptive. However, I find it easier to work with a codebase if > > > standard things like logging, toString, TODO comments etc are always > done > > > in the same way (unless there's exceptional circumstances). > > > > > > If you're interested in this topic I recommend that you use > Confluence's > > > "watch page" feature to keep track of further updates. > > > > > > Comments welcomed. > > > > > > Phil > > > > > > [1] > > https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards > > > [2] > > > > > > > > > https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards > > > > > >
