qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Wed, 05 Jun 2013 12:14:23 GMT
On 5 June 2013 13:00, Rafael Schloming <rhs@alum.mit.edu> 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 <robbie.gemmell@gmail.com
> >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 <phil@philharveyonline.com> 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
> > >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message