We have a requirement where userid information needs to be logged along with the message. The business layer is built with stateless session bean.
To log userid information we've used MDC. Achieved through 1. Added a Filter in the UI layer with the following code. A class AddDiagnosticDataFilter that implements the javax.servlet.Filter interface is added. This class implements the doFilter method in the Filter interface. The below given code snippet explains how diagnostic data is put to the MDC. try { HttpServletRequest req = (HttpServletRequest) servletRequest; HttpServletResponse res = (HttpServletResponse) servletResponse; HttpSession session = req.getSession(); UserSecurityImplementation userSecurity = (UserSecurityImplementation)session.getAttribute(USER_SECURITY_KEY); if (userSecurity != null) { MDC.put(“USER_ID”, userSecurity.getUserId()); } Chain.doFilter(request,response) } finally { MDC.remove(“USER_ID”); } 2. With EJBs , is this a robust solution to log diagnostic messages? The MDC API states that "The MDC is managed on a per thread basis. A child thread automatically inherits a copy of the mapped diagnostic context of its parent" Posting in http://java2.5341.com/msg/79763.html (read 7th page) states "Because EJBs are pooled by the container, subsequent requests by different clients may result in a previously created Bean being reused by another client other than the one who originally contacted the Bean for the first call (in the case of EntityBeans and StatelessSessionBeans... Not so for StatefulSessionBeans) Each incoming call executes in its own Thread, but it may not be a _NEW_ thread.. It may be an instance of a pooled bean that has already been created and already has a running ThreadContext. (in your PatternLayout add '%t' to the pattern and observe the Thread names that are logged between invocations). In this case anything that was previously pushed into the Thread Context would still be there upon the next invocation. If you always overwrite everything in the MDC everytime, you are probably safe. However, if you selectively add information based on some logic, you run the risk of seeing MDC information from the previous clients call. " My question is 1. After one EJB has finished serving first request and before removing the MDC from UI layer for the same request, is it possible that the bean (and in turn the running thread) be allocated to next request? This will cause the previous user id information to be logged erraneously. Will this happen? 2. By putting %t in logconfig xml, observed the logging thread pattern. The messages logged in the UI layer and the ones logged in EJB layer have the same thread. Won't the thread names logged from UI and EJB be different? (Assuming the thread invoked from Servlet context and EJB be different) 3. Had log messages in UI Layer(1) -> EJB Facade Layer(2) -> DAO Layer(3) -> EJB Facade Layer(4) -> UI Layer(5) MDC information was put(1) and removed in UI Layer(5) Later tried removing the diagnostic info (User id) from MDC in EJB Layer(Before 4) The user id information was not logged in EJB (4) and UI Layer(5). Does it mean both UI and EJB share the same thread context? Thanks, Ramaseshan -- View this message in context: http://www.nabble.com/MDC-and-EJB-tp18871590p18871590.html Sent from the Log4j - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]