commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [logging] Adding jndi java:env support
Date Fri, 13 Dec 2002 14:57:19 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message