Thanks Oleg, I have not though about this option.
Will try it.
It would be nice through to have getContentStream() method in 
EntityEnclosingMethod to facilitate
custom classes which would derive from EntityEnclosingMethod class.

--- Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:

> Riad,
> 
> A much, much better solution to this problem is to implement a custom
> RequestEntity class that can cleanly re-create the input stream:
> 
>
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/RequestEntity.html
> 
> Oleg
> 
> 
> On Fri, Jul 22, 2005 at 07:21:19AM -0700, Riad Souissi wrote:
> > Hi
> > 
> > - This issue appeared with version3 RC3 (I had no problem with RC1 and 
> > possibly RC2).
> > - I am sending a large file through HTTPClient. Since it is large, I avoid 
> > using buffering
> (stream
> > size is known, not equal to -1 or -2).
> > - When an error happen which involves the RetryHandler (derived from
> > DefaultHttpMethodRetryHandler), I used to reset the InputStream to position 
> > zero (either using
> > InputStream.mark(0) in the init phase then reset() or
> > ((FileInputStream)stream).getChannel().position(0) in JDK 1.4). This way, 
> > the retry mechanism
> will
> > reuse a properly initialized stream from its beginning.
> > 
> > This used to work, however, with RC3, it seems from the source code that
> InputStreamRequestEntity
> > is not repeatable anymore (which I can understand in case a stream cannot 
> > be reset, but in
> many
> > case, may be most cases, it can be reset and reused).
> > This causes the "Unbuffered entity enclosing request can not be repeated" 
> > error and faisl the
> HTTP
> > call.
> > 
> > This is the java stacktrace:
> > 
> > org.apache.commons.httpclient.ProtocolException: Unbuffered entity 
> > enclosing request can not
> be
> > repeated.
> >         at
> >
>
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:483)
> >         at 
> > org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
> >         at 
> > org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
> >         at
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:393)
> >         at
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
> >         at 
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
> >         at 
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
> > 
> > I wanted to rely fully on the RetryHandler of the HTTPClient rather than 
> > add another layer of
> > retrying on top of it, which I would like to avoid.
> > Do you guys have a nice solution ?
> > I would suggest that you make a method in InputStreamRequestEntity to force 
> > it to be
> repeatable if
> > the developer knows he can reuse and reset the stream. Is that possible ?
> > 
> > Thanks
> > riad
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to