You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Fruechtenicht, Torben" <TF...@ubis-ag.com> on 2003/07/01 17:56:06 UTC
AW: Multiple configuration files - single contra multiple hierarchies
Thomas,
I think I have done what you are trying to do - although I used property files and not XML. For my application I have two property files - one for the global stuff and one for that component which can exist in multiple instances. The last one contains a lot of placeholders some of which are filled by the Log4J mechanism, some are handled by my code (filling placeholders in property keys is not supported by log4j). I use these placeholders to fill in the names of my component instances so that the "instance" loggers can show up in the default hierarchy of loggers without any naming confusing. Below the named logger for each component instance, the hierarchy is the same for all because each component instance consists of the same set of sub-components.
So that should be your alternative 1. I didn't go for the second solution, looked like to much overhead to me. Other alternatives might be using NDC or MDC, haven't used that yet...
The disadvantage is that I have to configure some part of my logging programmatically...
Hope that helps in any way.
Torben
---
Torben Fruechtenicht
Developer
IT Solutions
UBIS AG fon: +49 30 39929-731
Dircksenstraße 42-44 fax: +49 30 39929-900
D-10178 Berlin email: tfruechtenicht@ubis-ag.com
Germany web: http://www.ubis-ag.com
---
> -----Ursprüngliche Nachricht-----
> Von: Thomas Muller [mailto:ttm@online.no]
> Gesendet: Montag, 30. Juni 2003 17:44
> An: log4j-user@jakarta.apache.org
> Betreff: Multiple configuration files - single contra multiple
> hierarchies
>
>
> Fellow Log4j users,
>
> Would appreciate some input on how to design a solution for a
> problem I'm
> facing regarding multiple Log4j configuration files.
>
> One of the modules in our system (the module consists of a significant
> number of classes) is in the process of being redesigned such that the
> system can handle multiple "instances" of it. The log
> configuration for the
> whole system is now contained in a single log4j XML
> configuration file, but
> in the new design the configuration will be distributed in order to
> accommodate the said requirement. Without any deep knowledge
> of Log4j, I
> believe I have two options regarding Logger naming schemes:
>
> 1. Use the same hierarchy for all modules
> 2. Use multiple hierarchies (one for each module).
>
> The consequence of 1) is that I must design a naming scheme
> such that Logger
> names in the different modules don't collide. A simple
> approach would be to
> add a suffix to each Logger name (i.e a module ID). E.g.
> Logger x, y, z
> would become x.ID1, y.ID1, z.ID1 for module ID1 and x.ID2,
> y.ID2, z.ID2 for
> module ID2. In this way the system can also benefit from
> accumulated logging
> (e.g. having a separate appender for Logger "x".
>
> The consequence of 2) is completely separate naming
> hierarchies for all
> modules, and consequently full freedom with respect to Logger
> naming. I will
> loose accumulated logging though.
>
> My question is; which approach do you consider best? How easy
> is 2) to set
> up/maintain? Are there any other approcaches that I've overlooked?
>
> We're using Log4j version 1.2.6.
>
> Any input/thoughs/ideas would be much appreciated.
>
> Thanks,
>
> --
>
> Thomas
>
>
>
>
> **************************************************************
> ***********
> Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All
> rights reserved.
> The information supplied in this Commercial Communication
> should be treated
> in confidence.
> No liability whatsoever is accepted for any loss or damage
> suffered as a result of accessing this message or any attachments.
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ______________________________________________________________
> __________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
RE: Multiple configuration files - single contra multiple hierarchies
Posted by Thomas Muller <tt...@online.no>.
Torben,
Thanks for the input. Seems like you've chosen a viable approach. May I
suggest you start using XML configuration files or incorporate interpolation
in PropertyConfigurator yourself?
The second option involves firing up new hierarchies and is actually not
that hard; you find an example in SocketAppender. I'm now lingering between
the two approaches, but I'm for various reasons a bit more inclined to go
for the separate hierarchies approach.
Again, thanks for your thoughts.
--
Thomas
| -----Original Message-----
| From: Fruechtenicht, Torben [mailto:TFruechtenicht@ubis-ag.com]
| Sent: 01 July 2003 16:56
| To: Log4J Users List; ttm@online.no
| Subject: AW: Multiple configuration files - single contra multiple
| hierarchies
|
|
| Thomas,
|
| I think I have done what you are trying to do - although I used
| property files and not XML. For my application I have two
| property files - one for the global stuff and one for that
| component which can exist in multiple instances. The last one
| contains a lot of placeholders some of which are filled by the
| Log4J mechanism, some are handled by my code (filling
| placeholders in property keys is not supported by log4j). I use
| these placeholders to fill in the names of my component instances
| so that the "instance" loggers can show up in the default
| hierarchy of loggers without any naming confusing. Below the
| named logger for each component instance, the hierarchy is the
| same for all because each component instance consists of the same
| set of sub-components.
| So that should be your alternative 1. I didn't go for the second
| solution, looked like to much overhead to me. Other alternatives
| might be using NDC or MDC, haven't used that yet...
| The disadvantage is that I have to configure some part of my
| logging programmatically...
|
| Hope that helps in any way.
|
| Torben
| ---
| Torben Fruechtenicht
| Developer
| IT Solutions
|
| UBIS AG fon: +49 30 39929-731
| Dircksenstraße 42-44 fax: +49 30 39929-900
| D-10178 Berlin email: tfruechtenicht@ubis-ag.com
| Germany web: http://www.ubis-ag.com
| ---
|
| > -----Ursprüngliche Nachricht-----
| > Von: Thomas Muller [mailto:ttm@online.no]
| > Gesendet: Montag, 30. Juni 2003 17:44
| > An: log4j-user@jakarta.apache.org
| > Betreff: Multiple configuration files - single contra multiple
| > hierarchies
| >
| >
| > Fellow Log4j users,
| >
| > Would appreciate some input on how to design a solution for a
| > problem I'm
| > facing regarding multiple Log4j configuration files.
| >
| > One of the modules in our system (the module consists of a significant
| > number of classes) is in the process of being redesigned such that the
| > system can handle multiple "instances" of it. The log
| > configuration for the
| > whole system is now contained in a single log4j XML
| > configuration file, but
| > in the new design the configuration will be distributed in order to
| > accommodate the said requirement. Without any deep knowledge
| > of Log4j, I
| > believe I have two options regarding Logger naming schemes:
| >
| > 1. Use the same hierarchy for all modules
| > 2. Use multiple hierarchies (one for each module).
| >
| > The consequence of 1) is that I must design a naming scheme
| > such that Logger
| > names in the different modules don't collide. A simple
| > approach would be to
| > add a suffix to each Logger name (i.e a module ID). E.g.
| > Logger x, y, z
| > would become x.ID1, y.ID1, z.ID1 for module ID1 and x.ID2,
| > y.ID2, z.ID2 for
| > module ID2. In this way the system can also benefit from
| > accumulated logging
| > (e.g. having a separate appender for Logger "x".
| >
| > The consequence of 2) is completely separate naming
| > hierarchies for all
| > modules, and consequently full freedom with respect to Logger
| > naming. I will
| > loose accumulated logging though.
| >
| > My question is; which approach do you consider best? How easy
| > is 2) to set
| > up/maintain? Are there any other approcaches that I've overlooked?
| >
| > We're using Log4j version 1.2.6.
| >
| > Any input/thoughs/ideas would be much appreciated.
| >
| > Thanks,
| >
| > --
| >
| > Thomas
| >
| >
| >
| >
| > **************************************************************
| > ***********
| > Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All
| > rights reserved.
| > The information supplied in this Commercial Communication
| > should be treated
| > in confidence.
| > No liability whatsoever is accepted for any loss or damage
| > suffered as a result of accessing this message or any attachments.
| >
| > ______________________________________________________________
| > __________
| > This email has been scanned for all viruses by the MessageLabs Email
| > Security System. For more information on a proactive email security
| > service working around the clock, around the globe, visit
| > http://www.messagelabs.com
| > ______________________________________________________________
| > __________
| >
| > ---------------------------------------------------------------------
| > To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
| > For additional commands, e-mail: log4j-user-help@jakarta.apache.org
| >
| >
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: log4j-user-help@jakarta.apache.org
|
|
*************************************************************************
Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All rights reserved.
The information supplied in this Commercial Communication should be treated
in confidence.
No liability whatsoever is accepted for any loss or damage
suffered as a result of accessing this message or any attachments.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org