I've never tried the NDC approach before... do you think it would work?
On Friday, February 16, 2001, at 07:55 PM, Scott M Stark wrote:
> I think you have part of the picture correct, but what I'm missing here
> is how all of the
> log msgs in code that the thread interacts with ends up getting
> associated with this
> 'UserDebug' category.
>
> For example, I'm using a Category per Java package paradigm in which
> every
> class in a package logs through a Category with a name equal to the
> package name.
> So, if the servlet interacts with two packages in addition to the
> servlet code,
> say com.dscape.security and com.dscape.mail, I want any msgs issued
> through
> the Category("com.dscape.security") and Category("com.dscape.mail") to
> show
> up in the Category("'UserDebug") appender regardless of their priority
> for this
> particular call stack only. If my understanding of Category is correct,
> I'm looking
> for a transient heirachy of Categorys based on the thread stack rather
> than any
> static category namespace.
>
> ----- Original Message -----
> From: Christopher Taylor
> To: LOG4J Users Mailing List
> Sent: Friday, February 16, 2001 6:56 PM
> Subject: Re: Using NDC to enable logging over a thread of control
>
>
> If I'm understanding your need correctly, you could probably do this in
> the following way without any code changes to Log4J:
>
> - if the user is authenticated, you can get the principal from the
> HttpServletRequest.
> - If that user has been "enabled for debugging", get an instance of a
> category for that user that is one step below a well-known
> debugging category (for example, category "UserDebug" logs to a special
> appender called "DebugUserProblems"). So, if I was
> authenticated with an SSL certificate any my distinguished name was
> "uid=ctaylor,dc=java-internals,dc=com", you could make the
> category name "UserDebug.ctaylor". One technique for doing this is to
> always get an instance of a category for logging in your
> application, but it depends if the user is on the debug list or not if
> calls go to the special log. You can put that instance of the
> Category into the request attributes.
>
> Let me know if I'm misinterpreting you.
>
> -Chris
>
> On Friday, February 16, 2001, at 06:50 PM, Scott M Stark wrote:
>
>
> I'm looking to correlate msgs with the active thread and to have the
> Priority of
> the thread override any Category.xxx() log msg invocation so that all
> log statements
> in this thread of control are rendered.
>
> The use case for this is a production J2EE server housing many EJBs,
> servlets, etc.
> and there is a problem report for particular user interacting with one
> servlet. I don't
> want to have to crank up the priority limit to dump out all possible
> msgs. I just want
> to toggle a request parameter that triggers logging throughout one
> particular thread of
> control the user is interacting with.
>
> ----- Original Message -----
> From: "Christopher Taylor" <[EMAIL PROTECTED]>
> To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Friday, February 16, 2001 6:27 PM
> Subject: Re: Using NDC to enable logging over a thread of control
>
>
>
> Could you go into a little more detail? Do you want to correlate
> messages with Threads
> or with clients?
>
> -Chris
>
> Scott M Stark wrote:
>
>
> One common logging task I use frequently in server development is the
> ability to
> enable logging across a thread of control beginning at some entry
> point. An example
> is enabling all log msgs regardless of priority that are executed
> within a particular
> servlet's service() method. Going through the log4j api I can't see a
> way to do this.
> Is this possible?
>
> ---------------------------------------------------------------------
> 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]
