Sushil, You might look into using a framework that supports Aspects, like Spring (http://www.springframework.org)... At which time it is very easy to transparently declare advice that uses aspects to inject standardized behavior behind the scenes of your EJB method calls (effectively giving you the equivalent single point of entry as a ServletFilter)
Also, some containers (notably jBoss) provide for an interceptor stack which can be manipulated to achieve the same goal, albeit in a more vendor specific approach. You can insert another interceptor into the stack which did the appropriate NDC/MDC manipulation. -d -----Original Message----- From: Sushil Sureka [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 23, 2005 5:09 PM To: Log4J Users List Subject: Re: NDC and multiple Ears in J2EE environment Thanks for replying. You are right that something like context can be used to put auxilary information (actually seems like weblogic 9.0 is going to make it easy based on what I read yesterday on bea website) The issue that would need to be addressed after that is at what point could NDC be populated. For Webtier, filter provides a single gateway into what ever happens on the web tier. But since there is no such thing on EJB tier, we would have to implement our own interceptor kind of thing to trap remote calls and populate NDC from EJB Context. Thanks Sushil On Mon, 21 Feb 2005 09:47:38 -0500, Donald Larmee <[EMAIL PROTECTED]> wrote: > Sorry for the delay in responding. This is not really a > function/issue of NDC, which is localized to log4j only. However, > depending on what sort of information you are trying to log, your > goals are accomplishable by using the EJB context to carry information > from the presentation tier to the business tier. > > Things like the Security principle associated with the request are > already transmitted (i.e., username, etc). With varying degrees of > difficulty, dependendent upon the actual container that you are using, > it is possible to inject your own extra material into constructs that > are pushed across as part of the context; thereby making them available on the service tier. > > For example, I have used this technique to push the webtiers sessionId > across so that in addition to the user/role credentials associated w/ > the request, it can be mapped to a specific servlet session id. > > The way I have accomplished this in the past is to install a Servlet > filter which pushes an implementation of the standard Principle > interface into the request stream. (NOTE: that this may not be as > easy as it sounds, depending on the container) > > Hope it helps, > > -d > > -----Original Message----- > From: Sushil Sureka [mailto:[EMAIL PROTECTED] > Sent: Monday, February 14, 2005 5:15 PM > To: [email protected] > Subject: NDC and multiple Ears in J2EE environment > > Hi, > > We have run into a small issue and wondering if anyone had any advice > on how to solve this. We have multiple ear and each ear initializes > its log service using its own log.xml. > > The issue is with the NDC and this set up. We have a filter set up to > set the NDC for each incoming request and the NDC messages shows up > fine for the web ear logs. But the problem is that when a remote call > is made to beans that are hosted in other ears, obviously the NDC is > getting lost since they are using two seperate instaces of Log4J. Is > there any easy way of making NDC somehow visible across two seperate instances of Log4J. > > -- > Thanks > Sushil > > --------------------------------------------------------------------- > 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] > > -- Thanks Sushil --------------------------------------------------------------------- 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]
