logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ebersole, Steven" <steven.ebers...@vignette.com>
Subject RE: MDC in J2EE environment
Date Thu, 03 Apr 2003 15:13:30 GMT
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:Yoav.Shapira@mpi.com]
    |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:steven.ebersole@vignette.com]
    |>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: log4j-user-unsubscribe@jakarta.apache.org
    |>For additional commands, e-mail: 
    |log4j-user-help@jakarta.apache.org
    |
    |
    |
    |
    |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: log4j-user-unsubscribe@jakarta.apache.org
    |For additional commands, e-mail: log4j-user-help@jakarta.apache.org
    |

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Mime
View raw message