At 22:44 12.12.2002 -0800, you wrote:
Craig R. McClanahan wrote:> I'm neutral on prefix versus suffix (although prefix feels a little more > in keeping with the hierarchical naming I tend to use for logging). But > that raises an important consideration -- do the underlying logging > implementations we support deal gracefully with a ":" syntax in a logger > name? In particlar, could I configure a logger for "DOMAIN:" and have it > apply to all loggers in that domain? I'm wondering if we might want to > use a period (".") as the connector instead. I don't know - that's why I ask :-) We should certainly use a syntax that is compatible with both jdk1.4 and log4j. We could encode the name - but it needs to be easy to type ( I hate %xx ). The only reason for suffix is easier configuration - but I'm not even sure it's easier :-) Can log4j or jdk14 support *.org.apache.commons.level=DEBUG ? The use case of setting the log level on a component in multiple applications seems more common.
Why do you want to prefix (or postfix) logger names? What is the goal? Is it security? If so, what do you do with the root logger? How can you prevent a malevolent application from simply getting the logger it wants by name?
We can leave the log name unchanged and try to play some tricks with the logger config. Changing the log name seemed like the easiest solution. We can associate the application name with the hierarchy - but again I don't know how this would work from a config perspective. Ceki - any idea ? The use case I have in mind is a container ( like tomcat ), with several applications, a JMX-based config tool and some centralised config file ( eventually managed by the JMX tool or editor or some other UI ). The apps shouldn't have to do anything - they should just see the normal log patterns as a standalone app today.
Log4j 1.2 API has most of what you need. The only missing piece is that logger repositories do not have names. If they had, you'd be able to manage multiple repositories in JMX. You can configure each logger repository separately (configurations act on logger repositories). Oh, there is no support for multiple logger repositories within a single configuration file but you can configure multiple repositories with multiple config files. Jacob Kjone has an implementation based on log4j 1.2.7 and for Tomcat 4.1.x. See: http://marc.theaimsgroup.com/?l=log4j-dev&m=103725695000410&w=2 See also http://marc.theaimsgroup.com/?l=log4j-dev&m=103975966220495&w=2
( of course - this should also work for jdk14 or other loggers - even if log4j is the best :-)
But of course! Would you like your miracle black or with sugar? :-) The things you want are so log4j specific that there is no way you can successfully abstract them without reproducing/copying log4j. JCL assumes that the important features of popular logging APIs can be abstracted. My hereto experience shows that abstracting independent APIs performing similar tasks is a major undertaking, much more arduous than one would initially think. I'd help more if I knew how.
Costin
-- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
