Hi Yoav,
The rub with this approach is that the MDC for a certain key might be set when it should be empty.
At 09:22 AM 4/3/2003 -0500, you wrote:
Howdy, My convention with MDC and NDC has been for each method to just worry about its own logging. For example:
In SessionBeanA: public void executeUseCase() // Put whatever you want into MDC // Log entry into SessionBeanA::executeUseCase ... // Call SessionBeanB::executeUseCaseB() ... // If you have more logging statements here, // need to re-populate MDC. }
In SessionBeanB: public void executeUseCaseB() // Put whatever you want into MDC // Log entry into SessionBeanB:executeUseCaseB() ... }
But the above may simply be my approach because I haven't had time to think of a better one. I also assume that populating an MDC is a very cheap operation: O(1) hash entries.
Yoav Shapira Millennium ChemInformatics
>-----Original Message----- >From: Ebersole, Steven [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 03, 2003 9:13 AM >To: Log4j user list (E-mail) >Subject: MDC in J2EE environment > >There is certain information which is thread contextual which I would like >to include into log4j's MDC to be available for logging. One of these, for >example, is the currently executing user. My architecture is such that all >requests come through a layer of stateless session EJBs. Now these EJBs >can >make calls into other session EJBs in order to fulfill their use-case: > >public class SessionBeanA >... >{ > ... > public void executeUseCase() > { > ... // Do some work > SessionBeanB sessionBeanB = ...; // Lookup SessionBeanB > sessionBeanB.executeSomeRelatedUseCase(); > ... // Do some more work > } >} > >public class SessionBeanB >... >{ > ... > public void executeRelatedUseCase() > { > ... // Do something > } >} > >The typical usage of MDC seems to be: >1) put vars into MDC >2) do your work >3) clean up MDC > >But if I apply this usage to the scenario above, when >SessionBeanB.executeRelatedUseCase() cleans up the MDC, the information >would no longer be contained in the MDC for LoggingEvents generated within >the "Do some more work" section of SessionBeanA.executeUseCase(). > >I run weblogic 6.1, which unfortunately does not have support for "call >interceptors" to know when a user context has been bound to a thread. >Otherwise, I could simply setup MDC when a "session" is begun and clean up >the MDC when the session ends. The only way around this I have been able >to >think of is to just always call MDC.put( "USER", >mySessionContext.getCallerPrincipal().getName() ) at the beginning of each >and every session bean method. But I would not ever be able to clean up >the >MDC because of this nesting described above. > >Is this OK? Or this there a better way to do this? > > > >Steve Ebersole >IT Integration Engineer >Vignette Corporation >Office: 512.741.4195 >Mobile: 512.297.5438 > >Visit http://www.vignette.com > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
