Re: Test classes - use assertEquals(exp,act) instead of assertTrue(actual=expected)?

2010-04-20 Thread Mike Dillon
Shouldn't that be assertSame() to retain the meaning of "=="? -md "sebb" wrote: >I just changed TestIdentityInputStream to use assertEquals(exp,actual) >rather than assertTrue(actual==exp), as this shows the actual and >expected values if the test fails. > >Any objections if I work through the

Re: JCIP annotations

2009-03-18 Thread Mike Dillon
begin sebb quotation: > It didn't work when I tried it last. Admittedly that was a few months > ago, and there has just been a new release. But I just tried again > with the following code: > > import net.jcip.annotations.GuardedBy; > public class GuardedByTest { > @GuardedBy("this") > p

Re: JCIP annotations

2009-03-17 Thread Mike Dillon
begin sebb quotation: > I've done most (perhaps all) of the HttpClient immutable classes, and > a few of the ones that are thread-safe (e.g. because access to mutable > objects is synchronized). > > [Findbugs seems to work reasonably well with @Immutable, but AFAIK it > does not process @GuardedBy

Re: Adding JCIP annotations to httpclient (and NIO)

2009-03-17 Thread Mike Dillon
s are so frickin' cool. > > Sam > > On Tue, Mar 17, 2009 at 7:10 PM, Mike Dillon wrote: > > begin sebb quotation: > >> On 17/03/2009, Oleg Kalnichevski wrote: > >> > sebb wrote: > >> > > >> > > The JCIP annotation jar >

Re: Adding JCIP annotations to httpclient (and NIO)

2009-03-17 Thread Mike Dillon
begin sebb quotation: > On 17/03/2009, Oleg Kalnichevski wrote: > > sebb wrote: > > > > > The JCIP annotation jar > > > > > > > > http://jcip.net/annotations/doc/net/jcip/annotations/package-summary.html > > > > > > is now available from Maven repos, so it might be a good idea to start > > > using

Re: Can an HTTP server close the socket before its client has finished receiving the message?

2008-07-11 Thread Mike Dillon
begin Oleg Kalnichevski quotation: > On Fri, 2008-07-11 at 19:19 +0200, Ortwin Glück wrote: > > > > Oleg Kalnichevski wrote: > > > The most plausible cause of this problem is a failure to flush the > > > output buffer on the server side. Given this is Weblogic, which is known > > > to be very stab