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]
