Yeah, that's what I was afraid of having to do.
I think I'll try just never clearing the MDC and see if that affects memory
really badly...
|-----Original Message-----
|From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
|Sent: Thursday, April 03, 2003 8:22 AM
|To: Log4J Users List
|Subject: RE: MDC in J2EE environment
|
|
|
|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]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
