On Tue, Jun 4, 2013 at 1:58 PM, Rajith Attapattu wrote:
> On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey wrote:
>
>> On 4 June 2013 18:54, Rajith Attapattu wrote:
>>
>> > I'm strongly against using dependencies for the JMS client unless it's
>> > unavoidable.
>> > We can make exception for slf4j, b
I don't think it's worth retaining any JMS Client coding standards so I've
removed the page.
I did however tweak the main coding standards [1] to briefly mention TODO
comments, made a couple of draconian rules "recommended" rather than
mandatory, and touched on documenting the thread-safety of cla
On 06/05/2013 12:00 PM, Rafael Schloming wrote:
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 integ
On 5 June 2013 13:00, Rafael Schloming 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 reas
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
r
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 th
Thanks for the responses. I hadn't appreciated the strength of feeling
against using external dependencies.
I disagree that using the commons-lang helper classes would yield code
that's more likely to contain errors, and also believe they yield more
readable code than the auto-generated version.
On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey wrote:
> On 4 June 2013 18:54, Rajith Attapattu wrote:
>
> > I'm strongly against using dependencies for the JMS client unless it's
> > unavoidable.
> > We can make exception for slf4j, but even then my preference is to use
> JDK
> > logging.
> >
>
> I
On 4 June 2013 18:54, Rajith Attapattu wrote:
> I'm strongly against using dependencies for the JMS client unless it's
> unavoidable.
> We can make exception for slf4j, but even then my preference is to use JDK
> logging.
>
If only JDK logging weren't so horrible :-)
> We've had several issue
I'm strongly against using dependencies for the JMS client unless it's
unavoidable.
We can make exception for slf4j, but even then my preference is to use JDK
logging.
We've had several issues dealing with dependencies in the past.
Increasingly our client is being used in various containers like
A
On 4 June 2013 18:37, Phil Harvey wrote:
> Ah, I expected a swift response about this. Luckily I'd already donned my
> tin hat :-)
>
> On 4 June 2013 17:16, Rob Godfrey wrote:
>
> > I'm not really a big fan of enforcing commons lang for toString -
> > sometimes you want/need to have a specific
Ah, I expected a swift response about this. Luckily I'd already donned my
tin hat :-)
On 4 June 2013 17:16, Rob Godfrey wrote:
> I'm not really a big fan of enforcing commons lang for toString -
> sometimes you want/need to have a specific string representation of an
> object.
Indeed - that'
I'm not really a big fan of enforcing commons lang for toString -
sometimes you want/need to have a specific string representation of an
object. Similarly I think we should be intelligent in defining equals and
hashCode() methods.
What I'd actually prefer to say is that every object should defin
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 re
14 matches
Mail list logo
