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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- 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]
