Re: [ANNOUNCEMENT] HttpComponents Core 4.4 GA released

[Gary Gregory]

It can take up to a day or two for a component to mirror around.

Gary

On Thu, Dec 18, 2014 at 10:12 PM, Shawn Heisey  wrote:
>
> On 12/18/2014 1:41 AM, Oleg Kalnichevski wrote:
> > The Apache HttpComponents project is pleased to announce 4.4 GA release
> > of HttpComponents Core.
>
> I'm trying to upgrade the Lucene-Solr codebase to use HC 4.4, but ivy
> can't find it.  It's missing from the maven repo that ivy tried to use
> for downloading:
>
> http://uk.maven.org/maven2/org/apache/httpcomponents/httpclient/
>
> When do you think the maven repo will have the new version, so that ivy
> can find it?
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ANNOUNCEMENT] HttpComponents Core 4.4 GA released

[Shawn Heisey]

On 12/18/2014 1:41 AM, Oleg Kalnichevski wrote:
> The Apache HttpComponents project is pleased to announce 4.4 GA release
> of HttpComponents Core. 

I'm trying to upgrade the Lucene-Solr codebase to use HC 4.4, but ivy
can't find it.  It's missing from the maven repo that ivy tried to use
for downloading:

http://uk.maven.org/maven2/org/apache/httpcomponents/httpclient/

When do you think the maven repo will have the new version, so that ivy
can find it?

Thanks,
Shawn


-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: Need a way to send a URL's stream as multi-part entity with repeatable blocks

[Joe Barnes]

Oh wow... I had not noticed that method on URL.  I'll certainly give it a
try.  Thanks!

Joe

On Thu, Dec 18, 2014 at 10:06 AM, Oleg Kalnichevski 
wrote:
>
> On Thu, 2014-12-18 at 09:23 -0600, Joe Barnes wrote:
> > Thanks for the insight, Oleg.  I was not aware that the key to
> > repeatability was knowing the length in advance.  That seems to suggest
> we
> > could have an API that accepted the stream and a length to produce a
> > repeatable multipart entity.
> >
> > As for converting the URLs to files, I'm not sure there is a clean way to
> > do that since we are running in a servlet container without access to the
> > file system.
>
> I was thinking about something rather trivial, like that:
>
> URL resource = Testing.class.getResource("/my-stuff.bin");
> File file = new File(resource.getFile());
> System.out.println(file + " exists: " + file.exists());
>
> Oleg
>
>
> >  I'll do some research and see if there is a means of making
> > this conversion that I'm not currently aware of.
> >
> > Joe
> >
> >
> > On Thu, Dec 18, 2014 at 3:17 AM, Oleg Kalnichevski 
> wrote:
> > >
> > > On Wed, 2014-12-17 at 17:37 -0600, Joe Barnes wrote:
> > > > Hello community!
> > > >
> > > > My team is faced with a problem where we need to send a resource
> that is
> > > > available via URL (more precisely, it is on our classpath).  We are
> > > running
> > > > in a servlet container, so we don't have direct access to the file
> > > system.
> > > > I completely understand why the chunks are marked as "Non-repeatable"
> > > when
> > > > using an InputStream, because in general they are not necessarily
> > > > repeatable.
> > > >
> > > > Currently we are reading the URL in its entirety to memory, then
> shipping
> > > > it off.  This is quite burdensome because of the size of the
> resources
> > > and
> > > > number of concurrent users we can expect.  The best we can do is
> create a
> > > > singleton of the value in memory, but it still is expensive for
> something
> > > > which could certainly be streamed.
> > > >
> > > > Are there any approaches we can utilize to send a URL's contents to a
> > > > multi-part while being repeatable without reading it entirely into
> > > memory?
> > > >
> > > > Thanks!
> > > > Joe
> > >
> > > Joe,
> > >
> > > Presently MultipartFormEntity cannot be repeated if length of any of
> its
> > > parts is unknown, which is the case with body parts backed by a
> > > InputStream or a URL. In your particular case, however, given that URLs
> > > represent local resources you should be able to convert them to File
> > > instances and thus make their length known in advance.
> > >
> > > Oleg
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > >
> > >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

How to get the parameters from HttpRequest?

[Johan Hertz]

Hi,

I am creating a class that implements the interface HttpRequestHandler.  
The handle method has a parameter of type HttpRequest on which I would 
expect to find the payload/parameters sent to the server. It does have a 
getParams method but it is deprecated. The deprecated message is /"use 
configuration classes provided 'org.apache.http.config' and 
'org.apache.http.client.config//"/.


Looking at this classes I can't seem to find what I am after, anyone 
know where I should look?


Regards
Johan

Re: Need a way to send a URL's stream as multi-part entity with repeatable blocks

[Oleg Kalnichevski]

On Thu, 2014-12-18 at 09:23 -0600, Joe Barnes wrote:
> Thanks for the insight, Oleg.  I was not aware that the key to
> repeatability was knowing the length in advance.  That seems to suggest we
> could have an API that accepted the stream and a length to produce a
> repeatable multipart entity.
> 
> As for converting the URLs to files, I'm not sure there is a clean way to
> do that since we are running in a servlet container without access to the
> file system. 

I was thinking about something rather trivial, like that:

URL resource = Testing.class.getResource("/my-stuff.bin");
File file = new File(resource.getFile());
System.out.println(file + " exists: " + file.exists());

Oleg


>  I'll do some research and see if there is a means of making
> this conversion that I'm not currently aware of.
> 
> Joe
> 
> 
> On Thu, Dec 18, 2014 at 3:17 AM, Oleg Kalnichevski  wrote:
> >
> > On Wed, 2014-12-17 at 17:37 -0600, Joe Barnes wrote:
> > > Hello community!
> > >
> > > My team is faced with a problem where we need to send a resource that is
> > > available via URL (more precisely, it is on our classpath).  We are
> > running
> > > in a servlet container, so we don't have direct access to the file
> > system.
> > > I completely understand why the chunks are marked as "Non-repeatable"
> > when
> > > using an InputStream, because in general they are not necessarily
> > > repeatable.
> > >
> > > Currently we are reading the URL in its entirety to memory, then shipping
> > > it off.  This is quite burdensome because of the size of the resources
> > and
> > > number of concurrent users we can expect.  The best we can do is create a
> > > singleton of the value in memory, but it still is expensive for something
> > > which could certainly be streamed.
> > >
> > > Are there any approaches we can utilize to send a URL's contents to a
> > > multi-part while being repeatable without reading it entirely into
> > memory?
> > >
> > > Thanks!
> > > Joe
> >
> > Joe,
> >
> > Presently MultipartFormEntity cannot be repeated if length of any of its
> > parts is unknown, which is the case with body parts backed by a
> > InputStream or a URL. In your particular case, however, given that URLs
> > represent local resources you should be able to convert them to File
> > instances and thus make their length known in advance.
> >
> > Oleg
> >
> >
> >
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >
> >



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: Need a way to send a URL's stream as multi-part entity with repeatable blocks

[Joe Barnes]

Thanks for the insight, Oleg.  I was not aware that the key to
repeatability was knowing the length in advance.  That seems to suggest we
could have an API that accepted the stream and a length to produce a
repeatable multipart entity.

As for converting the URLs to files, I'm not sure there is a clean way to
do that since we are running in a servlet container without access to the
file system.  I'll do some research and see if there is a means of making
this conversion that I'm not currently aware of.

Joe


On Thu, Dec 18, 2014 at 3:17 AM, Oleg Kalnichevski  wrote:
>
> On Wed, 2014-12-17 at 17:37 -0600, Joe Barnes wrote:
> > Hello community!
> >
> > My team is faced with a problem where we need to send a resource that is
> > available via URL (more precisely, it is on our classpath).  We are
> running
> > in a servlet container, so we don't have direct access to the file
> system.
> > I completely understand why the chunks are marked as "Non-repeatable"
> when
> > using an InputStream, because in general they are not necessarily
> > repeatable.
> >
> > Currently we are reading the URL in its entirety to memory, then shipping
> > it off.  This is quite burdensome because of the size of the resources
> and
> > number of concurrent users we can expect.  The best we can do is create a
> > singleton of the value in memory, but it still is expensive for something
> > which could certainly be streamed.
> >
> > Are there any approaches we can utilize to send a URL's contents to a
> > multi-part while being repeatable without reading it entirely into
> memory?
> >
> > Thanks!
> > Joe
>
> Joe,
>
> Presently MultipartFormEntity cannot be repeated if length of any of its
> parts is unknown, which is the case with body parts backed by a
> InputStream or a URL. In your particular case, however, given that URLs
> represent local resources you should be able to convert them to File
> instances and thus make their length known in advance.
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

Re: Need a way to send a URL's stream as multi-part entity with repeatable blocks

[Oleg Kalnichevski]

On Wed, 2014-12-17 at 17:37 -0600, Joe Barnes wrote:
> Hello community!
> 
> My team is faced with a problem where we need to send a resource that is
> available via URL (more precisely, it is on our classpath).  We are running
> in a servlet container, so we don't have direct access to the file system.
> I completely understand why the chunks are marked as "Non-repeatable" when
> using an InputStream, because in general they are not necessarily
> repeatable.
> 
> Currently we are reading the URL in its entirety to memory, then shipping
> it off.  This is quite burdensome because of the size of the resources and
> number of concurrent users we can expect.  The best we can do is create a
> singleton of the value in memory, but it still is expensive for something
> which could certainly be streamed.
> 
> Are there any approaches we can utilize to send a URL's contents to a
> multi-part while being repeatable without reading it entirely into memory?
> 
> Thanks!
> Joe

Joe,

Presently MultipartFormEntity cannot be repeated if length of any of its
parts is unknown, which is the case with body parts backed by a
InputStream or a URL. In your particular case, however, given that URLs
represent local resources you should be able to convert them to File
instances and thus make their length known in advance.

Oleg



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: hc-4.3.6: AllowAllVerifier not used

[Oleg Kalnichevski]

On Wed, 2014-12-17 at 19:28 +, Pete Keyes wrote:
> Thank you Oleg - very interesting.  The only information that I see in the
> JavaDoc is:
>   When a particular component is not explicitly this class will use its
> default
>   implementation. System properties will be taken into account when
> configuring
>   the default implementations when useSystemProperties() method is called
> prior
>   to calling build().
> 
> When I read that it would imply that anything not "customized" will
> fallback to the same value as provided by HttpClients.createDefault().
> Obviously, I was dead flat wrong in how I interpreted the documentation.
> 
>  Which of the following also lose their default behavior after going down
> the custom path?

Pete

HttpClientBuilder setter javadocs document which custom parameters are
mutually exclusive:

http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#setHostnameVerifier(org.apache.http.conn.ssl.X509HostnameVerifier)

Hope this helps

Oleg



-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

[ANNOUNCEMENT] HttpComponents Core 4.4 GA released

[Oleg Kalnichevski]

The Apache HttpComponents project is pleased to announce 4.4 GA release
of HttpComponents Core. 

Notable features included in the 4.4 series are:

* Support for pipelined request processing on the server side

* Support for pipelined request execution on the client side

* Simplified bootstrapping of blocking and non-blocking (NIO) HTTP
server implementations   

* Inclusion of SSL context initialization utilities from HttpClient

Please note that as of 4.4 HttpCore requires Java 1.6 or newer.

Download -

Release notes -

HttpComponents site - 


About HttpComponents Core

HttpCore is a set of low level HTTP transport components that can be
used to build custom client and server side HTTP services with a minimal
footprint. HttpCore supports two I/O models: a blocking I/O model based
on the classic Java I/O and a non-blocking, event driven I/O model based
on Java NIO.


-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org