Re: Question on HTTPClient-675

[D H <te...@gmail.com>]

Oleg,

It has taken some time, but the developers are going to make the recommended
changes that you and Ortwin suggested.

On Wed, Jun 17, 2009 at 2:25 PM, Oleg Kalnichevski <ol...@apache.org> wrote:

> D H wrote:
>
> You will be much better off using ServletContextListener to create and shut
> down MultiThreadedHttpConnectionManager and ServletContext to store the
> reference to that instance.
>
>> One should definitely use MultiThreadedHttpConnectionManager in a servlet
> container.
>

One question that one of our developers had was where to put the single
instance of MultiThreadedHttpConnectionManager to be able to use it across
threads from an EJB?
He will use the ServletContext and ServletContextListener for the
applications but isn't sure for EJBs.


> HttpClient 4.0 is _massively_ better than 3.x version and is better
> documented. You should tell your boss to seriously consider upgrading.
> Besides, 3.x code line is effectively at the end of life.
>
> It is just a matter of time I _personally_ will stop answering any
> questions about HttpClient 3.x


Believe it or not, once the developers saw that they had to upgrade, they
decided to go to the latest version themselves and only have to change the
code once so they are working to convert it now to 4.0.1.  I found the other
application having problems was running on the 2.0.2 version of HttpClient
but that will be fixed very soon.


> Cheers
> Evil Comrade Oleg


Thanks again for your help,
David Hamilton

Re: Question on HTTPClient-675

[Oleg Kalnichevski <ol...@apache.org>]

On Mon, Jul 20, 2009 at 09:52:42PM +0200, Ortwin Gl?ck wrote:
> David,
> 
> D H wrote:
> > One question that one of our developers had was where to put the single
> > instance of MultiThreadedHttpConnectionManager to be able to use it across
> > threads from an EJB?
> > He will use the ServletContext and ServletContextListener for the
> > applications but isn't sure for EJBs.
> 
> It's a bit of a matter of taste. I think it makes a good candidate for an MBean.
> If JBoss is your appserver, you can easily create a ServiceMBean for this
> purpose and set it up in the jboss-app.xml of your EAR or any other jboss.xml
> (of an EJB-JAR or SAR) of your choice. This way you could also easily add some
> MBean operations & properties for adminitrative purposes like flushing the
> cache, or returning statistics.
> 
> Odi
> 

I agree with Odi it all boils down to a matter of personal taste. There are a
few more options to consider

(1) JCA (JEE Connector Architecture) resource adaptor. Portable across
different JEE containers but horribly difficult to develop 


(2) If your applications needs to access resource from only one HTTP server (or
very few), my personal recommendation would be to wrap HttpClient plus a
_single_ connection connection manager into a stateless session bean and let
the JEE container take care of instance pooling and thread safety.

Hope this helps

Oleg


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: Question on HTTPClient-675

[Ortwin Glück <od...@odi.ch>]

David,

D H wrote:
> One question that one of our developers had was where to put the single
> instance of MultiThreadedHttpConnectionManager to be able to use it across
> threads from an EJB?
> He will use the ServletContext and ServletContextListener for the
> applications but isn't sure for EJBs.

It's a bit of a matter of taste. I think it makes a good candidate for an MBean.
If JBoss is your appserver, you can easily create a ServiceMBean for this
purpose and set it up in the jboss-app.xml of your EAR or any other jboss.xml
(of an EJB-JAR or SAR) of your choice. This way you could also easily add some
MBean operations & properties for adminitrative purposes like flushing the
cache, or returning statistics.

Odi

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org