hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Byrne <davidriby...@yahoo.com>
Subject Re: Final classes and methods
Date Fri, 16 May 2008 16:02:22 GMT
Thanks Oleg. I've been testing with using the same connection manager instance with two different
client classes, and everything is working very well.

David


----- Original Message ----
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Sent: Friday, May 16, 2008 3:40:32 AM
Subject: Re: Final classes and methods

On Thu, 2008-05-15 at 16:45 -0700, David Byrne wrote:
> Admittedly, it's not a common scenario. I want to add conditional logic to the process
method so that only some types of requests are modified.

Hi David

In case I would recommend implementing a custom protocol interceptor
that executes conditionally depending on the execution context (for
instance, if a certain runtime attribute is available in the context)


>  The underlying reason for this has to do with the nature of my project, which is a security
testing tool. Most requests are handled normally, but some need to be crafted in a specific
manner, without interceptor modification (the host header is a good example). 
> 
> Hmm... As I'm typing this, I an idea came to me. Originally, I had dismissed using a
separate client class because it would be difficult to tie the connection limits together.
What just occurred to me (duh), is that the connection manager is a separate object. The second
client class wouldn't use any request interceptors. Can you see any problems with sharing
the same instance of connection manager between two different client objects/classes?

It should not be a problem, I think

Oleg

> 
> Thanks,
> David
> 
> 
> ----- Original Message ----
> From: Oleg Kalnichevski <olegk@apache.org>
> To: HttpComponents Project <dev@hc.apache.org>
> Sent: Thursday, May 15, 2008 2:45:18 PM
> Subject: Re: Final classes and methods
> 
> On Thu, 2008-05-15 at 12:28 -0700, David Byrne wrote:
> > I'm curious why so many classes and methods are declared final. For example, I'd
like to extend BasicHttpProcessor, but it's final. Instead, I'm basically copying and pasting
into a new class, then modifying what I want. It's not the first time I've done that. Forgive
me if my question betrays a lack of understanding about proper class layout.
> > 
> 
> ´╗┐David,
> 
> If a class has been declared final, we thought there were no good
> reasons to extend those classes. Why would you want to derive a super
> class from ´╗┐BasicHttpProcessor? It is basically a container for protocol
> interceptors. Am I missing something?
> 
> Oleg
> 
> 
> 
> 
> > Thanks,
> > David Byrne
> > 
> > 
> >      
> > 
> > ---------------------------------------------------------------------
> > 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
> 
> 
>      
> 
> ---------------------------------------------------------------------
> 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


      

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


Mime
View raw message