jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Gaul <g...@apache.org>
Subject Re: JENKINS-23049
Date Tue, 27 May 2014 02:05:24 GMT
On Fri, May 23, 2014 at 06:28:58PM +0200, Andrew Phillips wrote:
> >I've just seen JENKINS-23049 [1], and I recall some changes in jclouds
> >to fix this.
> By the looks of it, this behaviour would be expected? Trying to
> upload a blob with a payload but no content length seems to be
> supposed to fail [1]. See JCLOUDS-508 [2] for a related comment, and
> an answer from Gaul to a Stack Overflow question [3].
> The only vaguely recent (over a year ago ;-)) change I can think of
> relating to content length is [4], but that's at a really low level.

Agree with your assessment.  JENKINS-23049 does not have enough context
to determine whether this is a regression or not; I suspect that someone
addressed a deprecation warning within Jenkins, changing a
ByteArrayPayload to a ByteSourcePayload.  The former gives an implicit
content length while the latter does not, yielding the symptoms

Unfortunately we cannot implicitly populate length efficiently for all
ByteSource implementations.  We could do something similar to the first
half of ByteSource.size, calling countBySkipping.  Or we could recommend
use of new Payloads.newPayload wrappers which populate length for byte[]
and File parameters.  I am not yet convinced that we need a solution to
this but encourage feedback on my ByteSource commits since some of this
API redesign is not straightforward.

Andrew Gaul

View raw message