qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Wed, 05 Jun 2013 11:00:35 GMT
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 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.

--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
> >
>

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