Roland,
As long as NDC is not supported by commons-logging HttpClient will not
be able to take full advantage of it. We can still think about some sort
of workaround as long as it does not make stock version of HttpClient
dependent on any particular logging toolkit. One idea that springs to
mind is to provide logging as an aspect using AspectJ or similar

Another possibility is, of course, introduce a logging toolkit
abstraction layer and abstract commons-logging away ;-)))

Oleg

On Tue, 2004-04-27 at 15:39, Roland Weber wrote:
> Hi Gareth,
> 
> thanks a lot for the pointer. The concept is very close to
> what I need. The problem is that I'm not using log4j, since
> the application uses a different logging framework. But
> I might borrow the idea of attaching some context to the
> thread in my application.
> 
> thanks again,
>   Roland
> 
> 
> 
> 
> 
> 
> [EMAIL PROTECTED]
> 27.04.2004 15:20
> Please respond to "Commons HttpClient Project"
>  
>         To:     "Commons HttpClient Project" 
> <[EMAIL PROTECTED]>
>         cc: 
>         Subject:        RE: customizing debugging levels per httpclient 
> instance
> 
> 
> 
> 
> 
> 
> 
> Best solution I've come up with for this sort of thing is to use Nested
> Diagnostic Context's (NDC) in log4j
> 
> have a look at the section on them in:
> http://logging.apache.org/log4j/docs/manual.html
> 
> Not quite what you want I know, but it will give you something to grep on.
> 
> Gareth
> 
> 
> 
>  
>              Roland Weber 
>              <[EMAIL PROTECTED] 
>              com>                                                       To 
> 
>                                        "Commons HttpClient Project" 
>              27/04/2004 14:12          <[EMAIL PROTECTED] 
> 
>                                        che.org> 
>                                                                         cc 
> 
>              Please respond to 
>                  "Commons                                          Subject 
> 
>                 HttpClient             RE: customizing debugging levels 
>                  Project"              per httpclient instance 
>              <commons-httpclie 
>              [EMAIL PROTECTED] 
>                  ache.org> 
>  
> 
> 
> 
> 
> 
> 
> Hi Oleg,
> 
> I had a similar problem when I started using HttpClient last year.
> Not thread-based though. I'm in a servlet engine, so I don't know
> which thread will be processing the request that uses HttpClient.
> I'd like to have different log settings per HttpClient instance, but
> that's not possible because they all use the same static loggers.
> 
> It's not a big issue for me now, since I have enough application
> level tracing. But if someone has an idea how this problem could
> be solved once and for all, it might be worth considering for 4.0.
> Like creating a logger for each HttpClient instance instead of
> each implementation class. Or falling back to the class logger
> only if no instance logger is configured in the params.
> 
> cheers,
>   Roland
> 
> 
> 
> 
> 
> 
> "Kalnichevski, Oleg" <[EMAIL PROTECTED]>
> 26.04.2004 18:34
> Please respond to "Commons HttpClient Project"
> 
>         To:     "Commons HttpClient Project"
> <[EMAIL PROTECTED]>
>         cc:
>         Subject:        RE: customizing debugging levels per httpclient
> instance
> 
> 
> 
> Jorrit,
> 
> HttpClient relies on commons-logging toolkit to do all its logging. The
> commons-logging itself is merely an abstraction layer intended to provide
> a uniform interface to different logging toolkits. If there is a toolkit
> capable of assigning different appenders on per thread basis, then
> HttpClient can be configured to take advantage of it. To my best knowledge
> Log4j cannot assign individual appenders to different threads within the
> same application (within the same class loader context rather). You may
> consider evaluating a different logging toolkit that provides such a
> feature, or file a feature request with the Log4j project.
> 
> 
> Oleg
> 
> 
> -----Original Message-----
> From: Jorrit Kronjee [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 26, 2004 13:19
> To: [EMAIL PROTECTED]
> Subject: customizing debugging levels per httpclient instance
> 
> 
> Hello,
> 
> I have an application consisting of two threads. Both threads have an
> 
> own instance of httpclient and use it for different things. I would like
> 
> to see the wire of one of the threads, but suppress the other. I use
> 
> log4j. log4j can set the debugging level (trace or not) based on
> 
> package/class names. I was wondering if it's possible to set the class
> 
> name for http client, so i can customize my debugging per thread. Or
> 
> perhaps I'm not understanding it correctly.
> 
> If this is not possible, I would like to make this a feature request.
> 
> Thanks in advance,
> 
> 
> Jorrit Kronjee
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 
> ***************************************************************************************************
> 
> The information in this email is confidential and may be legally
> privileged.  Access to this email by anyone other than the intended
> addressee is unauthorized.  If you are not the intended recipient of this
> message, any review, disclosure, copying, distribution, retention, or any
> action taken or omitted to be taken in reliance on it is prohibited and
> may be unlawful.  If you are not the intended recipient, please reply to
> or forward a copy of this message to the sender and delete the message,
> any attachments, and any copies thereof from your system.
> ***************************************************************************************************
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to