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