John,
I agree with your sentiments.
I'm using Log4j and find that colleagues are having the same problems as
many people on the mailing list, namely:
- not understanding that NDC method calls set up a stack of information per
thread.
- some specific problems are easily solved with post-processing work!
As long as the data is captured in log files, and you can parse through
them, what's the problem? Ideally, you want your app to run smoothly so
that you don't have to dig through log files in the first place. It's
better to spend time on the app than trying to come up with the ultimate
logging solution! (let Ceki and co. deal with that)
Rgds
Simon Liu
[EMAIL PROTECTED]
> -----Original Message-----
> From: John Volkar [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 7:21 PM
> To: LOG4J Users Mailing List
> Subject: RE: query in instantiations
>
> Huh? Please describe in detail why using NDC is not sufficent. From my
> personal experience NDC seems to meet all of my needs.
>
> Now it is possible that you want a log per thread for ease of reading...
> ???
> If so it's a simple matter to hack out a script that parses your master
> log
> file, and outputs messages only from some specified thread. (Or posibbly
> wait til the ThreadAppender mentioned on this mailing list earlier is
> contributed.)
>
> So far as "cost effects", have you observed an performance issue? Do not
> confuse calling Category.getInstance() as being the same as actually
> creating an instance each time it is called. Even if you take the
> approach
> that you described wherein you have one Category per Class per Thread, if
> you had 50 classes, and 10 threads, that is still only 500 Category
> instances.
>
> I agree this seems large, but it's not prohibitive, and it must really
> make
> your code look ugly. (I cannot even imagine the tedium involved there,
> what
> do you do? something like:
> synchronized(this){
> Category.getInstance(this.getClass() + " on "
> Thread.currentThread().getName()).debug("msg from some method.");
> }
> every time you want to log? yuck. Or are you tricky and use a ThreadLocal
> field to hold the category?
>
>
> Or perhaps, I've misread your message and missed your point. Anyway, I'd
> sugest NDC, and post-processing the log to solve your issue.
>
> Regards
> John Volkar
>
>
> -----Original Message-----
> From: amarnath [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 3:50 AM
> To: LOG4J Users Mailing List
> Subject: query in instantiations
>
>
> hi,
>
> B'fore the query, i need to explain the situation what i'm facing.
> The Current working model is an mutithreaded scenario.. where the
> 'n' number of classes accessed at time diffenrently. I need to
> identify which class the thread is currently accessing and need to
> know the Business Logic sequence currently in the flow.
>
> So i have to get the instance of Category class dynamically
> according classes which the thread is currently executing... so
> creating instances of Category class dynamically makes some pain,
> when executing in large process. Even though i tried with NDC, its
> helpful only in some Scenarios to identify... when i try to found
> any Error or Execptions from a class, i have to go only in
> particular class instantitions only.(for Dynamic instantiations)..
>
> can any gone give me a suggestion how to get the Instances of
> Category objects,which should give me the correct informations .
> (i.e) mainly by reducing the instantiation COST effects !!!
>
> And thanks in advance for valuble replies...
>
> cheers,
> Thambu
>
> ________________________________________________________________
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]
