I think MDC can really help because it is per thread and can be used with
out any extension to log4j, just add to your pattern in config file and set
in code when ever relevant.

On Tue, Aug 11, 2009 at 7:16 PM, sukesh jain <jainsuk...@hotmail.com> wrote:

>
> Hi,
>
> My problem is some what similar to one mentioned in this link (
> http://www.jajakarta.org/log4j/jakarta-log4j-1.1.3/docs/deepExtension.html
> )
>
> In brief, I am building an abstraction layer which encapsulates (through
> composition) logger object but user also passes additional information (say
> component name, classification of log messages (used by inhouse build
> viewing application) etc., Both component name and classification categories
> are in addition to FQCN i.e. logger names.) in each invocation of printing
> methods which need to be passed  through various components of logging
> framework say extending appender and layout class for finally written to its
> target destination. The user would specify the layout in the configuration
> file how to format the message.
>
> Example:
>
> public class Test {
> private static Logger logger = Logger.getLogger(Test);
>
> public void testmethod()
> {
>  logger.info(msg, componentName1, classification1...);
>  logger.info(msg);
> }
>
> public void testmethod1()
> {
>  logger.debug(msg, componentName2, classification2,...);
> }
> }
>
> So for each invocation of printing method (irrespective of levels) the
> additional information like componentName and classification can be
> different. Hence, this information need to be stored in loggingEvent (if I
> remember for each invocation of printing method loggingEvent object is
> created and hence, I need to extend it to pass this additional information
> so that finally layout object will format according to the pattern specified
> by user in the configuration file). Kindly let me know if the extension of
> loggingEvent method is appropriate one, if not then let me know how to
> proceed further. It would be of great help if pointers to some example is
> provided.
>
> If my example is not explainatory enough then kind let me know so that I
> will try to rephrase or provide more information.
>
> PS: Also let me know if setting a resourcebundle in a parent logger does it
> boils down to its children?
> As far as I looked and found that this setting of resource bundle cannot be
> achieved through configuration right?
>
> Regards,
> Jain
>
>
>
>
>
>
>
> > Date: Tue, 11 Aug 2009 17:26:00 +0200
> > From: c...@qos.ch
> > To: log4j-user@logging.apache.org
> > Subject: Re: Need Info/Documentation/Examples for extending log4j for
> additional fields/info
> >
> >
> > Hello Jain,
> >
> > Would you care to explain what is it that you are trying to accomplish?
> >
> > sukesh jain wrote:
> > >
> > > Hi all,
> > >
> > > I searched the Bugzilla repository and also the log4j manual, with the
> text
> > > "additional fields/info/properties" and "loggingEvent" but still did
> not found
> > > any pointers specifying how to add few custom fields or properties (I
> guess it
> > > must go to LoggingEvent) that would appear finally in the log files.
> > >
> > > As mentioned earlier I guess it has to be in LoggingEvent but while
> searching
> > > web, I found that it is not recommended or not the proper way as many
> issues
> > > are created because of it. Hence, I would like to know the pointers to
> proper
> > > way of achieving this.
> > >
> > > If someone has come across any documentation/examples it would be
> really
> > > helpful. Thanks in advance.
> > >
> > > Regards,
> > >
> > > Jain
> >
> > --
> > Ceki Gülcü
> > Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> > http://logback.qos.ch
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
>
> _________________________________________________________________
> We all see it as it is. But on MSN India, the difference lies in
> perspective.
> http://in.msn.com
>

Reply via email to