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 Thu, 15 May 2008 23:45:02 GMT
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. 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?

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


Mime
View raw message