logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: MDC in J2EE environment
Date Thu, 03 Apr 2003 15:32:48 GMT

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: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

--
Ceki 


---------------------------------------------------------------------
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