You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/01/05 12:45:27 UTC
[RT] Logging in 2.2
From time to time I'm thinking about how to simplify (if possible)
logging in Cocoon, so here we go again.
Currently we are using logkit for logging. It seems that we are more
or less the only project using logkit; everyone else is either
using log4j or commons-logging.
So, we create a small barrier for new users when it comes to configure
the logging as they are not used to logkit. Ok, this barrier is not
very high but it adds to the barrier Cocoon already has because of
its concepts etc. So, my question is, can or should we lower this barrier?
In the past we had several arguments about why logkit is better and so
on but I think most of these arguments are not valid any more.
We currently use the LogEnabled and Logger interface from the Avalon
Framework - these are not tied to any logging api. The interfaces
provide us IoC for logging.
Avalon provides a LoggerManager to plug in different logging apis,
by default we ship the manager for logkit, but it's possible to
use log4j etc. as well - but this requires additional configuration.
Now, a first and simple step could be to configure log4j as the default
and only those who really want to use logkit can change the
configuration. There were mainly two complaints about log4j: performance
and configuration features. Now, as we are using the Logger interface
from Avalon, we have a wrapper around the log4j logger anyway and
we can solve the performance problems in the wrapper. In fact,
this wrapper is already available. In addition we have a LoggerManager
that can read configuration files and replace placeholders with
current values, so we have the same features we have in our logkit.xconf.
But we could go further: we have a famous "hunt for removing all core
dependencies", so what about removing the dependency to Logkit completly?
I think it's sufficient to support one of the "standard" logging apis,
log4j or commons-logging (don't know which one is better), and that's it.
A very wired idea would be to use jdk1.4 logging, but I guess this
is too wild.
Why do we really need logkit? I honestly don't know.
The last step for me would be to remove the dependency to LogEnabled
(while still supporting it of course). I think we should decide for
the *one* logging api to use and provide an IoC way for this api.
Instead of using an own interface like LogEnabled, we support setter
and constructor injection. So if a component has a setLogger()
method for example, we pass a logger on construction. With ECM++
in place this is a piece of cake.
So my plan would be:
1. Decide for one logging api (log4j or commons-logging)
2. Remove the support for all other logging apis
3. Provide a IoC way for logging
4. Slowly move away from LogEnabled
If we still want to provide flexibility, we could opt for
commons-logging. In this case, brave users can configure logkit as the
logger for commons-logging and they are happy as well.
PS: Although I mention the "remove all dependencies" motivation, the
most important motivation for me is to simplify things - we shouldn't
make things too complicated.
Carsten
Re: [RT] Logging in 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
...
> If we still want to provide flexibility, we could opt for
> commons-logging. In this case, brave users can configure logkit as the
> logger for commons-logging and they are happy as well.
Think again before adopting the commons-logging API
http://www.qos.ch/logging/thinkAgain.jsp
Rod Waldhoff's Weblog: Commons Logging was my fault
http://radio.weblogs.com/0122027/2003/08/15.html
I would support this instead:
Universal and Generic Logging Interface (UGLI)
http://logging.apache.org/log4j/docs/ugli.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)
> 2. Remove the support for all other logging apis
> 3. Provide a IoC way for logging
> 4. Slowly move away from LogEnabled
>
> If we still want to provide flexibility, we could opt for
> commons-logging. In this case, brave users can configure logkit as the
> logger for commons-logging and they are happy as well.
I am +1 on commons-logging and -1 on using log4j directly. I have to be
able to use my own logging framework, which I can currently do with
logkit very easily.
Ralph
Re: [RT] Logging in 2.2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Ugo Cei wrote:
> Il giorno 05/gen/05, alle 12:45, Carsten Ziegeler ha scritto:
>
>> 1. Decide for one logging api (log4j or commons-logging)
>
>
> +1 for commons-logging
>
>> 2. Remove the support for all other logging apis
>
>
> +1
>
>> 3. Provide a IoC way for logging
>> 4. Slowly move away from LogEnabled
>
>
+1 on commons logging.
Has anyone been able to properly configure logging on cocoon + jetty
5.0? It has switched to commons-logging and jetty logging configuration
conflicts with logkit.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 10:14, Torsten Curdt dijo:
>>> Most of all, I'd like to see the AbstractLogEnabled class die a quick
>>> and painful death ;-)
>
> Since we are talking...
>
> ...what about using e.g. http://just4log.sourceforge.net from
> the build system. I *hate* the isBlaEnabled crap (although
> it of course makes sense using it).
>
> IMO it really bloats the source code and harms the
> readability of the source code.
>
> ...and that's not what logging statements are supposed
> to do.
I like that too!
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
>> Most of all, I'd like to see the AbstractLogEnabled class die a quick
>> and painful death ;-)
Since we are talking...
...what about using e.g. http://just4log.sourceforge.net from
the build system. I *hate* the isBlaEnabled crap (although
it of course makes sense using it).
IMO it really bloats the source code and harms the
readability of the source code.
...and that's not what logging statements are supposed
to do.
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 05/gen/05, alle 12:45, Carsten Ziegeler ha scritto:
>
>> 1. Decide for one logging api (log4j or commons-logging)
>
>
> +1 for commons-logging
>
>> 2. Remove the support for all other logging apis
>
>
> +1
+1
>> 3. Provide a IoC way for logging
>> 4. Slowly move away from LogEnabled
>
>
> Most of all, I'd like to see the AbstractLogEnabled class die a quick
> and painful death ;-)
LOL
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/gen/05, alle 12:45, Carsten Ziegeler ha scritto:
> 1. Decide for one logging api (log4j or commons-logging)
+1 for commons-logging
> 2. Remove the support for all other logging apis
+1
> 3. Provide a IoC way for logging
> 4. Slowly move away from LogEnabled
Most of all, I'd like to see the AbstractLogEnabled class die a quick
and painful death ;-)
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
log4j is the de facto standard. Commons-logging provide flexibility:
<snip
src="http://jakarta.apache.org/commons/logging/guide.html#Introduction">
JCL provides thin-wrapper Log implementations for other logging tools,
including Log4J , Avalon LogKit , the Avalon Framework's logging
infrastructure, JDK 1.4, and an implementation of JDK 1.4 logging APIs
(JSR-47) for pre-1.4 systems. The interface maps closely to Log4J and
LogKit.
</snip>
I am +1 on commons-logging using log4j.
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
Ralph Goers wrote:
> I guess I would just leave the Avalon Logger constructs in and change the
> default implementation to use the JDK logger. Lose the dependency on
> logkit.
...and provide good documentation on how to hook in
other log implementations.
Does not sound too bad to me.
What about just4log? ...it does not yet support Avalon Logger.
...but it should fairly easy to add.
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> I guess I would just leave the Avalon Logger constructs in and change the
> default implementation to use the JDK logger. Lose the dependency on
> logkit.
>
>
Yes, loosing the dependency on logkit is imho good; but in the long term
we want to loose the dependency to avalon as well (read again: long
term), so my idea was to install an alternative *today* to provide a
long migration period.
Carsten
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
I guess I would just leave the Avalon Logger constructs in and change the
default implementation to use the JDK logger. Lose the dependency on
logkit.
Carsten Ziegeler said:
> Hmm, I'm a little bit lost in this thread :(
>
> The easiest thing of course would be to just leave everything as it is
> and move to a different subject. But using a logging framework that
> noone else uses just feels not right for me.
>
> Has anyone a clue on how to procede?
>
> Carsten
>
>
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Fri, 07 Jan 2005 12:26:12 +0100, Torsten Curdt <tc...@apache.org> wrote:
> >> IMO this only leads to mixing of concepts.
> >
> >
> > What concepts? Remember that python and Java 1.5 have this capability,
> > because it's useful... are they both so wrong?
>
> No ...it *is* useful!! ...a variable amount
> of parameters!
Bah, I don't like varargs that much, it's just syntax sugar adding
opacity in exchange for a few keystrokes. The compiler is changing
varargs into arrays, and the receiving method needs to be written
against an array anyway, so why bother?
> >> Some people will
> >> use the "{}" some won't. To be honest I would not feel very happy
> >> with UGLI since IMHO this interface is only half-backed. Sorry.
> >
> >
> > Half baked because it has "the parameter stuff"?
>
> Either make it use the 1.5 stuff (and make
> 1.5 a requirement) or leave it out ...but
> this mixture is what I call half baked.
>
> > Remember that log4j uses that interface. Is log4j also half-baked?
Not quite, but still this shaky interface adds up to the list of Log4J
poorly engineered stuff that makes me wish for an interface to isolate
myself from it (even though I do reckon that we have to suppport it
given how pervasive it has become). UGLI looks like the less worst
alternative, so I can digest it. But getting to like that... well,
that's entirely another issue.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>
> So let's drop this topic and finish the virtual sitemap components.
> Someone?
There is some code in 2.2, in VirtualPipelineGenerator, complete with a running
sample and list of TODOs. Anybody can continue the started work - but I'd
personally concentrate on 2.1.7 (and failing tests, and bugs) first.
Vadim
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefano Mazzocchi wrote:
>
> Carsten, too early. Now that avalon is closed, nobody is going to modify
> those classes in a non-compatible way.
That's true.
>
> There is *less* to worry about now than in the past.
>
>
> Let's try to act rationally people, if ain't broken, don't try to fix it.
>
I'm not worrying about avalon (or excalibur) and their future. Once we
had the agreement to move away from marker interfaces to POJOs - one
remaining piece for this is in fact logging. But it's true that we don't
have to do it today, we have time. Personally I like to introduce an
alternative very early in time and have a long migration phase. But I
have no problem with leaving things as they are.
So let's drop this topic and finish the virtual sitemap components. Someone?
Carsten
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Torsten Curdt wrote:
>
>>>> Is there any technical reason to switch from the Avalon Logger
>>>> abstraction?
>>>
>>>
>>>
>>> No.
>>
>>
>>
>> Well ...then that's no good reason to me.
>>
>> Rather I would also import the few classes
>> into out repository (like we did with ECM)
>> than doing the switch.
>>
> We can't import the classes in this case as these are interfaces. For
> ECM we could provide our own implementation, but - for now - we are
> still using the interfaces of the avalon framework. We agreed to move
> away someday from these interfaces - and part of this logging discussion
> is exactly about this: moving away from the avalon interfaces.
Carsten, too early. Now that avalon is closed, nobody is going to modify
those classes in a non-compatible way.
There is *less* to worry about now than in the past.
Let's try to act rationally people, if ain't broken, don't try to fix it.
--
Stefano.
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> Hmm, we have discussed this topic very lengthy and to summarize
> it, we don't want to have dependencies for the core which
> translates to: we don't want the core to depend on avalon.
> On the technical side this means: moving from marker interfaces to POJOs.
>
> With ECM++ ..eh..our own container, we are free to do what we want and
> we can provide a smooth migration path.
Ok, so copy the interfaces from Avalon and name then o.a.c.whatever.
Ralph
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Torsten Curdt wrote:
>
> They would no longer be the "avalon interfaces"
> ..or is the ECM++ still avalon?
>
> What was the reason again to move exchange the
> abstraction layer? ...not talking about the
> implementation.
>
> Sorry, guys this discussion getting a bit absurd to me.
Hmm, we have discussed this topic very lengthy and to summarize
it, we don't want to have dependencies for the core which
translates to: we don't want the core to depend on avalon.
On the technical side this means: moving from marker interfaces to POJOs.
With ECM++ ..eh..our own container, we are free to do what we want and
we can provide a smooth migration path.
Carsten
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Torsten Curdt <tc...@apache.org>.
>>>> Is there any technical reason to switch from the Avalon Logger
>>>> abstraction?
>>>
>>> No.
>>
>> Well ...then that's no good reason to me.
>>
>> Rather I would also import the few classes
>> into out repository (like we did with ECM)
>> than doing the switch.
>>
> We can't import the classes in this case as these are interfaces. For
> ECM we could provide our own implementation, but - for now - we are
> still using the interfaces of the avalon framework.
...well interfaces then - whatever.
> We agreed to move
> away someday from these interfaces - and part of this logging discussion
> is exactly about this: moving away from the avalon interfaces.
They would no longer be the "avalon interfaces"
..or is the ECM++ still avalon?
What was the reason again to move exchange the
abstraction layer? ...not talking about the
implementation.
Sorry, guys this discussion getting a bit absurd to me.
--
Torsten
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Carsten Ziegeler <cz...@apache.org>.
Torsten Curdt wrote:
>>> Is there any technical reason to switch from the Avalon Logger
>>> abstraction?
>>
>>
>> No.
>
>
> Well ...then that's no good reason to me.
>
> Rather I would also import the few classes
> into out repository (like we did with ECM)
> than doing the switch.
>
We can't import the classes in this case as these are interfaces. For
ECM we could provide our own implementation, but - for now - we are
still using the interfaces of the avalon framework. We agreed to move
away someday from these interfaces - and part of this logging discussion
is exactly about this: moving away from the avalon interfaces.
Carsten
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Torsten Curdt <tc...@apache.org>.
>> IMO this only leads to mixing of concepts.
>
>
> What concepts? Remember that python and Java 1.5 have this capability,
> because it's useful... are they both so wrong?
No ...it *is* useful!! ...a variable amount
of parameters!
>> Some people will
>> use the "{}" some won't. To be honest I would not feel very happy
>> with UGLI since IMHO this interface is only half-backed. Sorry.
>
>
> Half baked because it has "the parameter stuff"?
Either make it use the 1.5 stuff (and make
1.5 a requirement) or leave it out ...but
this mixture is what I call half baked.
> Remember that log4j uses that interface. Is log4j also half-baked?
Also with the parameters? ...wasn't aware
of that ...but my opinion would still apply.
>> ...and I don't see point of getting rid of the Avalon Logger
>> dependency and introducing the UGLI dependency instead. Only
>> because we want to get rid of Avalon?
>
> Yes.
>
>> Is there any technical reason to switch from the Avalon Logger
>> abstraction?
>
> No.
Well ...then that's no good reason to me.
Rather I would also import the few classes
into out repository (like we did with ECM)
than doing the switch.
cheers
--
Torsten
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Torsten Curdt wrote:
>
>>> If you prefer commons logging over it, please write a technical
>>> motivation about it.
>>
>>
>> As I already said: I don't see the point of this parameter stuff.
>
>
> Then don't use the parameter stuff.
>
>> IMO this only leads to mixing of concepts.
>
>
> What concepts? Remember that python and Java 1.5 have this capability,
> because it's useful... are they both so wrong?
>
>> Some people will
>> use the "{}" some won't. To be honest I would not feel very happy
>> with UGLI since IMHO this interface is only half-backed. Sorry.
>
>
> Half baked because it has "the parameter stuff"?
>
> Remember that log4j uses that interface. Is log4j also half-baked?
>
>> ...and I don't see point of getting rid of the Avalon Logger
>> dependency and introducing the UGLI dependency instead. Only
>> because we want to get rid of Avalon?
>
>
> Yes.
>
>> Is there any technical reason to switch from the Avalon Logger
>> abstraction?
>
>
> No.
People, enough bike shedding already.
Nicola, UGLI is a nice attempt and an improvement over existing stuff,
but Torsten is right: without Java 1.5/python/C unlimited parameter
passing style, it's clearly a hack.
Carsten understimated the amount of establishment (rational or
irrational) on top of the existing logging environments.
I say we move on to move important things.
--
Stefano.
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Torsten Curdt wrote:
>> If you prefer commons logging over it, please write a technical
>> motivation about it.
>
> As I already said: I don't see the point of this parameter stuff.
Then don't use the parameter stuff.
> IMO this only leads to mixing of concepts.
What concepts? Remember that python and Java 1.5 have this capability,
because it's useful... are they both so wrong?
> Some people will
> use the "{}" some won't. To be honest I would not feel very happy
> with UGLI since IMHO this interface is only half-backed. Sorry.
Half baked because it has "the parameter stuff"?
Remember that log4j uses that interface. Is log4j also half-baked?
> ...and I don't see point of getting rid of the Avalon Logger
> dependency and introducing the UGLI dependency instead. Only
> because we want to get rid of Avalon?
Yes.
> Is there any technical reason to switch from the Avalon Logger
> abstraction?
No.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging
in 2.2)
Posted by Torsten Curdt <tc...@apache.org>.
> If you prefer commons logging over it, please write a technical
> motivation about it.
As I already said: I don't see the point of this parameter stuff.
IMO this only leads to mixing of concepts. Some people will
use the "{}" some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?
Is there any technical reason to switch from the Avalon Logger
abstraction?
cheers
--
Torsten
[Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>> Carsten Ziegeler wrote:
>>
>> How about leaving everything as is and just change the default logger
>> to be log4j instead of logkit?
>>
> Hm, yeah, why not :( It seems that everyone is using different logging
> approaches, so a consensus is impossible. Sigh.
Wait, not all is lost.
Let's restart with the points I think we agree upon.
1: we want to get rid of Avalon dependency
-> get rid of logkit
2: there seems to be a general like of log4j as an implementation
-> use log4j as a standard implementation
3: we want a logging abstraction, not be tied to a concrete impl
-> use commons logging or UGLI
These points have brought us to almost say yes to Commons Logging +
Log4j as predefined implementation.
Then I came up with proposing UGLI as an alternative abstraction, as it
has the *same* advantages of commons logging without the configuration
nightmare drawbacks, has some extra niceties, and is supported by log4j,
which is the implementation that we tend to prefer.
Now, it seems to me that nobody is against UGLI instead of commons
logging for a logging abstraction, as all things against UGLI have
nothing to do with the comparison with commons logging but just about
the extra features it has, which seem not so important.
Now, I propose that we use UGLI as a logging abstraction and log4j as
the predefined logging package.
Here is the UGLI logging interface [1].
If you prefer commons logging over it, please write a technical
motivation about it.
"
package org.apache.ugli;
public interface ULogger {
public boolean isDebugEnabled();
public void debug(Object msg);
public void debug(Object parameterizedMsg, Object param1);
public void debug(String parameterizedMsg, Object param1,
Object param2);
public void debug(Object msg, Throwable t);
public boolean isInfoEnabled();
public void info(Object msg);
public void info(Object parameterizedMsg, Object param1);
public void info(String parameterizedMsg, Object param1,
Object param2);
public void info(Object msg, Throwable t);
public boolean isWarnEnabled();
public void warn(Object msg);
public void warn(Object parameterizedMsg, Object param1);
public void warn(String parameterizedMsg, Object param1,
Object param2);
public void warn(Object msg, Throwable t);
public boolean isErrorEnabled();
public void error(Object msg);
public void error(Object parameterizedMsg, Object param1);
public void error(String parameterizedMsg, Object param1,
Object param2);
public void error(Object msg, Throwable t);
}
"
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ULogger.java?rev=1.2&view=markup
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Logging in 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefano Mazzocchi wrote:
> Carsten Ziegeler wrote:
>
>
> How about leaving everything as is and just change the default logger to
> be log4j instead of logkit?
>
Hm, yeah, why not :( It seems that everyone is using different logging
approaches, so a consensus is impossible. Sigh.
Carsten
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Hmm, I'm a little bit lost in this thread :(
>
> The easiest thing of course would be to just leave everything as it is
> and move to a different subject. But using a logging framework that
> noone else uses just feels not right for me.
>
> Has anyone a clue on how to procede?
How about leaving everything as is and just change the default logger to
be log4j instead of logkit?
--
Stefano.
[SUMMARY] Logging in 2.2
Posted by peter royal <pr...@apache.org>.
On Jan 6, 2005, at 9:46 AM, Carsten Ziegeler wrote:
> Hmm, I'm a little bit lost in this thread :(
>
> The easiest thing of course would be to just leave everything as it is
> and move to a different subject. But using a logging framework that
> noone else uses just feels not right for me.
>
> Has anyone a clue on how to procede?
* Cocoon currently uses the Avalon Framework logger abstraction
* Cocoon currently uses Logkit as the default underlying logging
implementation
(1) Developers wish to continue to use a logging abstraction within
Cocoon
(2) Developers wish to move away from Logkit as the default underlying
logging implementation
Choices for (1) are:
* status-quo (Avalon Framework logging abstraction)
* UGLI
* commons-logging
Choices for (2) are:
* JDK 1.4 Logging
* log4j
* status-quo (logkit)
I believe the main push might be for #2, so that users can configure a
logging system they are familiar with. The choice of #1 shouldn't
matter to most users.
-pete
Re: [RT] Logging in 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Hmm, I'm a little bit lost in this thread :(
The easiest thing of course would be to just leave everything as it is
and move to a different subject. But using a logging framework that
noone else uses just feels not right for me.
Has anyone a clue on how to procede?
Carsten
Re: [RT] Logging in 2.2
Posted by peter royal <pr...@apache.org>.
On Jan 6, 2005, at 3:10 AM, Carsten Ziegeler wrote:
> the only difference is that we move away from LogEnabled
> and that we directly use an existing logging api.
I'd be vehemently -1 on a change to tie cocoon to a concrete logging
api. I like how it only depends on a logging abstraction at the moment.
-pete
Re: [RT] Logging in 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>
> Nono, the performance problem is in Log4J itself: checking if a log
> level is enabled on a category is costly and involves crawling up the
> category tree up to finding an ancestor which has an explicit setting
> for this (see Category.isDebugEnabled and Category.getEffectiveLevel);
>
Yes, the performance problem is in Log4j - but the log4j wrapper for
LogEnabled covers this problem. It detects on initialization the current
log level and stores this information locally. So a call to
isDebugEnabled is directly answered by the wrapper.
>> In fact, this wrapper is already available. In addition we have a
>> LoggerManager
>> that can read configuration files and replace placeholders with
>> current values, so we have the same features we have in our logkit.xconf.
>
>
>
> Sorry, I don't follow you here. What is this placeholder feature?
>
You can use properties like ${context-root} in the log4j configuration.
>> But we could go further: we have a famous "hunt for removing all core
>> dependencies", so what about removing the dependency to Logkit completly?
>
>
>
> Again, we have a dependency on the Avalon Logger API, not to a
> particular logger API. That's exactly the same for the Service Manager.
>
We are trying to move away from the avalon interfaces. Yes, sure
LogEnabled and Logger are not tied to logkit, but we ship logkit by
default - all our configuration for logging is for logkit. So we depend
on logkit.
>
>> Instead of using an own interface like LogEnabled, we support setter
>> and constructor injection. So if a component has a setLogger()
>> method for example, we pass a logger on construction. With ECM++
>> in place this is a piece of cake.
>
>
>
> How's that really different from LogEnabled? The object will still be
> tied to the Logger interface, which lives just beside LogEnabled...
>
Yes, but it's avalon free :) Ok, seriously with setter or constructor
injection your components work in Cocoon, but you can also use them
in spring or whereever because other containers can handle this
kind of injection. It's not bad to be tied to a specific logging api
that everyone is using - but it's bad to be tied to a framework
(avalon) that noone is using.
> <SNIP/>
>
> Your proposal omits an important point: why do we use IoC loggers? The
> classical way of getting a Category in log4j is to use :
> private static Logger logger = Logger.getLogger(Blah.class);
>
> That leads to a topological organization of logger hierarchies (it's the
> class name) whereas IoC-style logger the way we do it using the "logger"
> attribute allows for a functional organization of hierarchies, as we can
> group logs of related components into a single category whatever their
> class name, thus easing filtering.
>
> Furthermore, logkit (the implementation, not the Avalon Logger API) also
> provides the topological information by allowing to output the name of
> the calling class along with the category.
>
No no no :) As I said, I don't want to move away from IoC, you can still
set the logger from the outside, so functional organization is still
possible - the only difference is that we move away from LogEnabled
and that we directly use an existing logging api.
Carsten
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> We are not using logkit: we are using Avalon Logger, and the default
> configuration shipped with Cocoon use the LogKit implementation of
> Avalon Logger (you say the same below).
true
>> Why do we really need logkit? I honestly don't know.
>
>
> Because it's not bloated?
well ...I think keeping an abstraction layer
is not a bad idea. But the question which one
to use... so this would be more about
commons-logging vs avalon logging vs UGLI.
As for the abstraction layers I cannot really
say which one of those is more bloated than
the other. But since we a lot of components
are already relying on commons-logging the
question is whether is makes sense to get
rid of another dependency.
For 2.2 we have jdk 1.4 as a requirement
so we *could* ship without *any* logging
implementation ...and everyone could just
plug in what ever he wants.
That's one thing...
> Your proposal omits an important point: why do we use IoC loggers? The
> classical way of getting a Category in log4j is to use :
> private static Logger logger = Logger.getLogger(Blah.class);
>
> That leads to a topological organization of logger hierarchies (it's the
> class name) whereas IoC-style logger the way we do it using the "logger"
> attribute allows for a functional organization of hierarchies, as we can
> group logs of related components into a single category whatever their
> class name, thus easing filtering.
...if you chose to get the logger from the class.
Which you don't have to do.
But you are right. I probably the most important
question is: do we need or do we want IoC style
logging.
> - I certainly don't want to start again something similar to the
> migration from Loggable (logkit-specific) to LogEnabled (not talking
> also of Composable to Serviceable).
I hear you ...such big changes *are* a PITA.
And we need see whether it's worth it. For
me I see UGLI being ruled out until someone
can provide a good reason to switch. As
already being pointed out - we still need the
isBlaEnabled stuff with it. No matter whether
in source code or added at build time.
So I see it like that:
commons-logging
o one dependencies less
o not IoC
o potential classloader issues(?)
avalon logging
o nothing to change
o IoC
...I am not a friend of IoC-logging anymore.
But whether that's worth the change? Don't know...
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> From time to time I'm thinking about how to simplify (if possible)
> logging in Cocoon, so here we go again.
>
> Currently we are using logkit for logging. It seems that we are more
> or less the only project using logkit; everyone else is either
> using log4j or commons-logging.
We are not using logkit: we are using Avalon Logger, and the default
configuration shipped with Cocoon use the LogKit implementation of
Avalon Logger (you say the same below).
> So, we create a small barrier for new users when it comes to configure
> the logging as they are not used to logkit. Ok, this barrier is not
> very high but it adds to the barrier Cocoon already has because of
> its concepts etc. So, my question is, can or should we lower this
> barrier?
>
> In the past we had several arguments about why logkit is better and so
> on but I think most of these arguments are not valid any more.
Why? What has changed?
> We currently use the LogEnabled and Logger interface from the Avalon
> Framework - these are not tied to any logging api. The interfaces
> provide us IoC for logging.
> Avalon provides a LoggerManager to plug in different logging apis,
> by default we ship the manager for logkit, but it's possible to
> use log4j etc. as well - but this requires additional configuration.
>
> Now, a first and simple step could be to configure log4j as the default
> and only those who really want to use logkit can change the
> configuration. There were mainly two complaints about log4j: performance
> and configuration features. Now, as we are using the Logger interface
> from Avalon, we have a wrapper around the log4j logger anyway and
> we can solve the performance problems in the wrapper.
Nono, the performance problem is in Log4J itself: checking if a log
level is enabled on a category is costly and involves crawling up the
category tree up to finding an ancestor which has an explicit setting
for this (see Category.isDebugEnabled and Category.getEffectiveLevel);
> In fact, this wrapper is already available. In addition we have a
> LoggerManager
> that can read configuration files and replace placeholders with
> current values, so we have the same features we have in our logkit.xconf.
Sorry, I don't follow you here. What is this placeholder feature?
> But we could go further: we have a famous "hunt for removing all core
> dependencies", so what about removing the dependency to Logkit completly?
Again, we have a dependency on the Avalon Logger API, not to a
particular logger API. That's exactly the same for the Service Manager.
> I think it's sufficient to support one of the "standard" logging apis,
> log4j or commons-logging (don't know which one is better), and that's it.
> A very wired idea would be to use jdk1.4 logging, but I guess this
> is too wild.
> Why do we really need logkit? I honestly don't know.
Because it's not bloated?
> The last step for me would be to remove the dependency to LogEnabled
> (while still supporting it of course). I think we should decide for
> the *one* logging api to use and provide an IoC way for this api.
Doesn't LogEnabled provide an implementation-independent IoC way?
> Instead of using an own interface like LogEnabled, we support setter
> and constructor injection. So if a component has a setLogger()
> method for example, we pass a logger on construction. With ECM++
> in place this is a piece of cake.
How's that really different from LogEnabled? The object will still be
tied to the Logger interface, which lives just beside LogEnabled...
> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)
IMO, log4j and commons-logging cannot be compared : log4j is an
implementation whereas commons-logging is an abstract API which
provides, among others, and implementation based on log4j.
> 2. Remove the support for all other logging apis
> 3. Provide a IoC way for logging
> 4. Slowly move away from LogEnabled
>
> If we still want to provide flexibility, we could opt for
> commons-logging. In this case, brave users can configure logkit as the
> logger for commons-logging and they are happy as well.
>
> PS: Although I mention the "remove all dependencies" motivation, the
> most important motivation for me is to simplify things - we shouldn't
> make things too complicated.
Then maybe it's just a matter of changing the syntax of logkit.xconf?
Your proposal omits an important point: why do we use IoC loggers? The
classical way of getting a Category in log4j is to use :
private static Logger logger = Logger.getLogger(Blah.class);
That leads to a topological organization of logger hierarchies (it's the
class name) whereas IoC-style logger the way we do it using the "logger"
attribute allows for a functional organization of hierarchies, as we can
group logs of related components into a single category whatever their
class name, thus easing filtering.
Furthermore, logkit (the implementation, not the Avalon Logger API) also
provides the topological information by allowing to output the name of
the calling class along with the category.
So, my POV on this is:
- we use Avalon Logger that can be mapped to logkit, log4j, whatever.
- I'm happy with logkit although I don't want to refrain people to use
something else
- I certainly don't want to start again something similar to the
migration from Loggable (logkit-specific) to LogEnabled (not talking
also of Composable to Serviceable).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Logging in 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bernard D'Have wrote:
> Hi,
> Just a pointer to a thread aout UGLI in Jakarta HttpClient:
> http://mail-archives.apache.org/eyebrowse/BrowseList?listName=httpclient-dev
> @jakarta.apache.org&by=thread&from=967502
Since the URL of this archive may break in the infra reorg that is
happening, here is IMHO the point:
"
Since the org.apache.log4j.Logger class is a direct implementation of
org.apache.ugli.ULogger interface, there is no need to wrap a log4j
Logger to conform to the UGLI interface. Log4j Loggers are already
ULoggers. It follows that the objects returned by
o.a.ugli.LoggerFactory.getLogger("x") are identical to those returned
by o.a.log4j.Logger.getLogger("x").
Thus, using UGLI in conjunction with log4j will not carry any overhead
whatsoever.
As noted in my previous message, UGLI also supports parameterized log
messages obliterating the need to surround log messages with
logger.isXXXEnabled checks.
Instead of writing:
if(logger.isDebugEnabled()) {
logger.debug("User with "+id+" entered wrong query string
["+query"]." );
}
you can just write:
logger.debug("User with {} entered wrong query string [{}].", id,
query);
Give or take a nano-second, when the log statement is disabled, both
forms perform equally well but the second form is easier to read and
to write.
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Logging in 2.2
Posted by Bernard D'Have <bd...@tiscali.be>.
Hi,
Just a pointer to a thread aout UGLI in Jakarta HttpClient:
http://mail-archives.apache.org/eyebrowse/BrowseList?listName=httpclient-dev
@jakarta.apache.org&by=thread&from=967502
Bernard
-----Original Message-----
From: peter royal [mailto:proyal@apache.org]
Sent: Wednesday, January 05, 2005 2:22 PM
To: dev@cocoon.apache.org
Subject: Re: [RT] Logging in 2.2
On Jan 5, 2005, at 6:45 AM, Carsten Ziegeler wrote:
> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)
> 2. Remove the support for all other logging apis
> 3. Provide a IoC way for logging
> 4. Slowly move away from LogEnabled
>
> If we still want to provide flexibility, we could opt for
> commons-logging. In this case, brave users can configure logkit as the
> logger for commons-logging and they are happy as well.
My only requirement is that we continue to have the ability to plug
cocoon into a logging hierarchy that is larger than itself. Using
either commons-logging or the new UGLI interfaces from log4j will
satisfy this.
-pete
Re: [RT] Logging in 2.2
Posted by peter royal <pr...@apache.org>.
On Jan 5, 2005, at 6:45 AM, Carsten Ziegeler wrote:
> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)
> 2. Remove the support for all other logging apis
> 3. Provide a IoC way for logging
> 4. Slowly move away from LogEnabled
>
> If we still want to provide flexibility, we could opt for
> commons-logging. In this case, brave users can configure logkit as the
> logger for commons-logging and they are happy as well.
My only requirement is that we continue to have the ability to plug
cocoon into a logging hierarchy that is larger than itself. Using
either commons-logging or the new UGLI interfaces from log4j will
satisfy this.
-pete
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> There is also a slight issue with Log4J in its dealings with runtime
> dependencies and classloading that may hurt future efforts in Cocoon in "true
> blocks".
I don't know if this is true anymore. Our new kernel is able to use
dependency injection and static factories together so that you get the
benefit of IoC without the pain.
It's true that Log4j is more complex than JAXP, but I don't think it's
that big of a difference.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
I don't believe getting rid of (Abstract)LogEnabled should be done in 2.2.
That is so pervasive that it will significantly delay getting a 2.2
release out soon.
Torsten Curdt said:
>> Maybe just throw away (Abstract)LogEnabled and do constructor injection
>> instead. Or even relegate Logging to an ordinary service, which is
>> looked up
>> like any other component.
>
> As much as I like IoC I think logging is one of the reasons for
> overcomponentization. ...just because you need a logger instance.
> Passing it to the POM does not make it much nicer. In fact it's
> sometimes hard to draw the line. Component ...not a component.
>
> Have logging as an explicit service does definitely not feel
> right to me. Logging should be much more low-level!
>
> I am not sure but to me IoC seems to hurt more than it helps
> for logging. May I play devils advocate:
> For how many projects would this *really* be a security issue?
> If someone can log to your logger you probably have bigger
> problems!
>
> ...and btw: if you need to you *can* get to any logging channel
> even with logkit IIRC.
>
> cheers
> --
> Torsten
>
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> Why? Nothing prevents you from writing:
> Blah blah = new Blah();
> blah.setLogger(getLogger());
Nothing ...as long as a LogEnabled creates
the object.
>> Passing it to the POM does not make it much nicer. In fact it's
>> sometimes hard to draw the line. Component ...not a component.
>
> Uh? "POM"?
Aehm ...I meant POJO
>> Have logging as an explicit service does definitely not feel right to
>> me. Logging should be much more low-level!
>
>
>
> A big +1. *That* would lead to over-componentization !
>
>> I am not sure but to me IoC seems to hurt more than it helps for
>> logging. May I play devils advocate:
>> For how many projects would this *really* be a security issue?
>> If someone can log to your logger you probably have bigger problems!
>>
>> ...and btw: if you need to you *can* get to any logging channel even
>> with logkit IIRC.
>
>
>
> Yup: Hierarchy.getDefaultHierarchy().getLogger("any.category");
There you go...
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Curdt wrote:
>> Maybe just throw away (Abstract)LogEnabled and do constructor
>> injection instead. Or even relegate Logging to an ordinary service,
>> which is looked up like any other component.
>
>
> As much as I like IoC I think logging is one of the reasons for
> overcomponentization. ...just because you need a logger instance.
Why? Nothing prevents you from writing:
Blah blah = new Blah();
blah.setLogger(getLogger());
> Passing it to the POM does not make it much nicer. In fact it's
> sometimes hard to draw the line. Component ...not a component.
Uh? "POM"?
> Have logging as an explicit service does definitely not feel right to
> me. Logging should be much more low-level!
A big +1. *That* would lead to over-componentization !
> I am not sure but to me IoC seems to hurt more than it helps for
> logging. May I play devils advocate:
> For how many projects would this *really* be a security issue?
> If someone can log to your logger you probably have bigger problems!
>
> ...and btw: if you need to you *can* get to any logging channel even
> with logkit IIRC.
Yup: Hierarchy.getDefaultHierarchy().getLogger("any.category");
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> Maybe just throw away (Abstract)LogEnabled and do constructor injection
> instead. Or even relegate Logging to an ordinary service, which is looked up
> like any other component.
As much as I like IoC I think logging is one of the reasons for
overcomponentization. ...just because you need a logger instance.
Passing it to the POM does not make it much nicer. In fact it's
sometimes hard to draw the line. Component ...not a component.
Have logging as an explicit service does definitely not feel
right to me. Logging should be much more low-level!
I am not sure but to me IoC seems to hurt more than it helps
for logging. May I play devils advocate:
For how many projects would this *really* be a security issue?
If someone can log to your logger you probably have bigger
problems!
...and btw: if you need to you *can* get to any logging channel
even with logkit IIRC.
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 06 January 2005 00:43, Gianugo Rabellino wrote:
> On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
>
> <cz...@apache.org> wrote:
> > In the past we had several arguments about why logkit is better and so
> > on but I think most of these arguments are not valid any more.
>
> Well, AFAIU a big one still stands true: security. I really hate the
> idea that other code can write to my channel just by doing a
> Logger.getLoggerFor().
There is also a slight issue with Log4J in its dealings with runtime
dependencies and classloading that may hurt future efforts in Cocoon in "true
blocks".
Ex, If I have a running instance and decides to change the Log4J configuration
to include an Appender that has an additional runtime dependency (javamail
for instance) than is available from the Logger classloader (which they
recommend to be the most top level CL one can manage to put it in), then you
will need to bring down the entire server.
This is the result of missing separation of interface and implementation,
missing classloader strategy and total lack of IoC, and during Merlin days we
were trying hard to stop depend on LogKit and make a full port to Log4J, but
the work seemed overwhelming and the Log4J folks were a bit lost of why this
is a problem for long-running applications.
I also agree with Nicola's pointer of the problems with commons-logging, and
to use it, you will need to throw away the factory and use your own IoC
pattern, but then, that is essentially same as the current Logger
interface...
Maybe just throw away (Abstract)LogEnabled and do constructor injection
instead. Or even relegate Logging to an ordinary service, which is looked up
like any other component.
Cheers
Niclas
--
---------------
If you want the rainbow, you gotta put up with the rain.
- Steven Wright
+---------//-------------------+
| http://www.dpml.net |
| http://niclas.hedhman.org |
+------//----------------------+
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
> <cz...@apache.org> wrote:
>
>
>>In the past we had several arguments about why logkit is better and so
>>on but I think most of these arguments are not valid any more.
>
>
> Well, AFAIU a big one still stands true: security. I really hate the
> idea that other code can write to my channel just by doing a
> Logger.getLoggerFor().
That goes away with classloading isolation.
> But hey, that's life... all in all syslogd has
> been around for quite some time and works exactly that way, so let's
> move on.
Agreed.
> I tend to back the UGLI logging interface ATM...
Yeah, I think Nicola has good points. I also love the fact that UGLI
doesn't mess with the classloader, making it easier for us to implement
classloading isolation down the road.
> but I just
> love Torsten's just4log suggestion as well. Yeah, something I'm still
> missing is the good old -DDEBUG swistch...
I'm +0 on this.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
<cz...@apache.org> wrote:
> In the past we had several arguments about why logkit is better and so
> on but I think most of these arguments are not valid any more.
Well, AFAIU a big one still stands true: security. I really hate the
idea that other code can write to my channel just by doing a
Logger.getLoggerFor(). But hey, that's life... all in all syslogd has
been around for quite some time and works exactly that way, so let's
move on. I tend to back the UGLI logging interface ATM... but I just
love Torsten's just4log suggestion as well. Yeah, something I'm still
missing is the good old -DDEBUG switch...
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> Because Ralph is a brave user ;-)
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110493608032769&w=2
ups... missed that one :-)
thanks
--
Torsten
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 14:06, Torsten Curdt dijo:
>> -1 on log4j (from me)
>> -1 on jdk logger (from me - same reason as log4j)
>
> Could you give a more detailed explanation
> why both are not working for you?
Because Ralph is a brave user ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110493608032769&w=2
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 05 Jan 2005 22:30:16 +0100, Torsten Curdt <tc...@apache.org> wrote:
> > I think that's my point? If you want to sub in three things do it as
> > normal String building and ignore the parameters substitution. Or use
> > 2 parameters and one Java variable directly in the String... Nothing
> > has gone away with UGLI, you just get some extra methods you can
> > ignore if you want?
>
> ...and why would you want to go through the hassle and switch from
> logkit then?
So you don't have to use logkit? (it wasn't my idea to switch)...
> Where is the benefit of using UGLI then?
--
Peter Hunsberger
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> I think that's my point? If you want to sub in three things do it as
> normal String building and ignore the parameters substitution. Or use
> 2 parameters and one Java variable directly in the String... Nothing
> has gone away with UGLI, you just get some extra methods you can
> ignore if you want?
...and why would you want to go through the hassle and switch from
logkit then? Where is the benefit of using UGLI then?
--
Torsten
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 14:56, Peter Hunsberger dijo:
> On Wed, 5 Jan 2005 14:21:01 -0600 (CST), Antonio Gallardo
> <ag...@agssa.net> wrote:
>> On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
>> > On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt <tc...@apache.org>
>> > wrote:
>> > <snip>other loggers</snip>
>> >>
>> >> > and it looks like -1 on UGLI from Torsten.
>> >>
>> >> Well, I doubt I have to give a -1 with
>> >> the given facts... :-P
>> >
>> > What's to stop everyone from continuing to just construct the Strings
>> > like they do today and not use the UGLI parameter substitution? Isn't
>> > the fact that it can do substitution on up to two parameters just the
>> > equivalent of some extra convenience methods? Or is there something
>> > else I missed?
>>
>> Because UGLI allows only 2 parameters substitutions (you cannot
>> substitute
>> 3 parameters). And this is not a big deal.
>
> I think that's my point? If you want to sub in three things do it as
> normal String building and ignore the parameters substitution. Or use
> 2 parameters and one Java variable directly in the String... Nothing
> has gone away with UGLI, you just get some extra methods you can
> ignore if you want?
Just for the records,
We will still need to use isDebugEnable().
Best Regards,
Antonio Gallardo.
Re: [RT] Logging in 2.2
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 5 Jan 2005 14:21:01 -0600 (CST), Antonio Gallardo
<ag...@agssa.net> wrote:
> On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
> > On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt <tc...@apache.org>
> > wrote:
> > <snip>other loggers</snip>
> >>
> >> > and it looks like -1 on UGLI from Torsten.
> >>
> >> Well, I doubt I have to give a -1 with
> >> the given facts... :-P
> >
> > What's to stop everyone from continuing to just construct the Strings
> > like they do today and not use the UGLI parameter substitution? Isn't
> > the fact that it can do substitution on up to two parameters just the
> > equivalent of some extra convenience methods? Or is there something
> > else I missed?
>
> Because UGLI allows only 2 parameters substitutions (you cannot substitute
> 3 parameters). And this is not a big deal.
I think that's my point? If you want to sub in three things do it as
normal String building and ignore the parameters substitution. Or use
2 parameters and one Java variable directly in the String... Nothing
has gone away with UGLI, you just get some extra methods you can
ignore if you want?
--
Peter Hunsberger
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
>>What's to stop everyone from continuing to just construct the Strings
>>like they do today and not use the UGLI parameter substitution?
What's the bonus of switching then?
Maybe we need some more input on UGLI.
>> Isn't
>>the fact that it can do substitution on up to two parameters just the
>>equivalent of some extra convenience methods? Or is there something
>>else I missed?
Well, convenience ...hm ...I am no big fan of mixing concepts
> Because UGLI allows only 2 parameters substitutions (you cannot substitute
> 3 parameters). And this is not a big deal.
Not a big deal? ...at least for me it would rule out that approach.
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 14:14, Peter Hunsberger dijo:
> On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt <tc...@apache.org>
> wrote:
> <snip>other loggers</snip>
>>
>> > and it looks like -1 on UGLI from Torsten.
>>
>> Well, I doubt I have to give a -1 with
>> the given facts... :-P
>
> What's to stop everyone from continuing to just construct the Strings
> like they do today and not use the UGLI parameter substitution? Isn't
> the fact that it can do substitution on up to two parameters just the
> equivalent of some extra convenience methods? Or is there something
> else I missed?
Because UGLI allows only 2 parameters substitutions (you cannot substitute
3 parameters). And this is not a big deal.
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 05 Jan 2005 21:06:14 +0100, Torsten Curdt <tc...@apache.org> wrote:
<snip>other loggers</snip>
>
> > and it looks like -1 on UGLI from Torsten.
>
> Well, I doubt I have to give a -1 with
> the given facts... :-P
What's to stop everyone from continuing to just construct the Strings
like they do today and not use the UGLI parameter substitution? Isn't
the fact that it can do substitution on up to two parameters just the
equivalent of some extra convenience methods? Or is there something
else I missed?
--
Peter Hunsberger
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> So far we have:
>
> -1 on commons-logging (from Nicola)
So it seems quite a few people have
been bitten by this ...question is:
Why not fix it?
> -1 on log4j (from me)
> -1 on jdk logger (from me - same reason as log4j)
Could you give a more detailed explanation
why both are not working for you?
> and it looks like -1 on UGLI from Torsten.
Well, I doubt I have to give a -1 with
the given facts... :-P
> That leaves logkit and just4log (which I haven't looked at). Unless
> someone has something else?
...we just started the discussion ;-)
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> >> very pythonish. I like it :-)
> >
> > ...but only with jdk 1.5 :-/
>
> Not AFAIK.
>
> [1] http://logging.apache.org/log4j/docs/ugli.html
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ULogger.java?rev=1.2&view=markup
Two paramters ...and variable arguments lists
are only supported since java 1.5.
So we would be back at constructing the Strings
and need the isBlaEnabled check.
...so is there any other benefit over other
logging abstractions?
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Keeping it simple... we all kinda want log4j but don't want to link
directly to the implementation... UGLI is the lightweight frontend that
gives us log4j with pluggability [1].
"
Note that log4j version 1.3 and later support UGLI directly as log4j
itself is implemented in terms of the UGLI interface.
"
Antonio Gallardo wrote:
...
> 1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
> true, then UGLI is not a serious proposal.
That's not the goal of UGLI, just an extra feature.
Please read this [1] first, don't assume that what you read on this
thread is all there is to it.
Torsten Curdt wrote:
>>> logger.debug("User with {} entered wrong query string [{}].", id,
>>> query);
>>> "
>>
>> very pythonish. I like it :-)
>
> ...but only with jdk 1.5 :-/
Not AFAIK.
[1] http://logging.apache.org/log4j/docs/ugli.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Logging in 2.2
Posted by Peter Hunsberger <pe...@gmail.com>.
On Wed, 5 Jan 2005 23:40:52 +0100, Ugo Cei <ug...@apache.org> wrote:
> Il giorno 05/gen/05, alle 21:56, Antonio Gallardo ha scritto:
>
> > 1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
> > true, then UGLI is not a serious proposal. Should be discarded. It is
> > only
> > a bad produced syntax sugar. I must admit, the idea with more
> > parameters
> > is really cool. Maybe in the future we can adopt it. I know we don't
> > have
> > some too heavy logging requirements. I mean I need 10's of parameters
> > or
> > recursive logging.
>
> If you have more than two parameters, you can always use string
> concatenation with an isDebugEnabled() guard. UGLI does not take away
> anything in this regard.
Yah, I just pointed that out a couple of messages ago and Torsten
responded by asking why you shoudl bother switching in that case...
--
Peter Hunsberger
Re: [RT] Logging in 2.2
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/gen/05, alle 21:56, Antonio Gallardo ha scritto:
> 1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
> true, then UGLI is not a serious proposal. Should be discarded. It is
> only
> a bad produced syntax sugar. I must admit, the idea with more
> parameters
> is really cool. Maybe in the future we can adopt it. I know we don't
> have
> some too heavy logging requirements. I mean I need 10's of parameters
> or
> recursive logging.
If you have more than two parameters, you can always use string
concatenation with an isDebugEnabled() guard. UGLI does not take away
anything in this regard.
Ugo
--
Ugo Cei - http://beblogging.com/blojsom/blog/
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:
I think we are still discussing the topic. It is to early to cast it as
real votes.
just4log is a complement to [log4j | commons-logging | JDK 1.4 Logging ]
if all three are deprecated, then we can not use it. :-(
Unfortunately seems like we will still stall with logkit?
No package is a nirvana. Each one has own pluses and minuses.
How I see things:
1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
true, then UGLI is not a serious proposal. Should be discarded. It is only
a bad produced syntax sugar. I must admit, the idea with more parameters
is really cool. Maybe in the future we can adopt it. I know we don't have
some too heavy logging requirements. I mean I need 10's of parameters or
recursive logging.
2-commons-logging: Software evolves and comments that where true 2 or 3
years ago are not true now. I think is posible to find mails of people
telling "don't try to build databases system with cocoon" (or a similar
with a topic) that are 2 or 3 years old. And we know that some of them are
not true now. Not sure if this is the same with commons-logging. Perhaps
we need to review it again and see if commons-logging evolved over the
time. I am wondering how other Apache libraries are using it and why and
how they can live with commons-logging.
3-jdk logger 1.4: Perhaps the same as log4j, but we will still include
log4j in our distribution.
4-Logkit: Carsten proposal was mostly to get rid of a package (LogKit)
that seems to be cocoon's exclusive usage. I also remember the problems
needing to learn logkit => just "another brick" in the learning curve
"wall". BTW, anybody is working on it?
Until now you can beat that I am in favor of commons-logging. I am +0. I
prefer log4j + just4log combination. :-)
Best Regards,
Antonio Gallardo.
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 15:02, Jean Pierre LeJacq dijo:
> On Wed, 5 Jan 2005, Stefano Mazzocchi wrote:
>
>> Ralph Goers wrote:
>> > So far we have:
>> >
>> > -1 on commons-logging (from Nicola)
>> > -1 on log4j (from me)
>> > -1 on jdk logger (from me - same reason as log4j)
>> > and it looks like -1 on UGLI from Torsten.
>> >
>> > That leaves logkit and just4log (which I haven't looked at). Unless
>> > someone has something else?
>>
>> I don't want to escalate this unnecessarely, but the above should be
>> treated as votes, not vetos.
>>
>> My point being: it might be wise not to change things too much ("if
>> ain't broken don't fix it" and all that) but at the same time, it's
>> getting kind of ridiculous that we are the only users of a particular
>> API.
>>
>> Can you tell us more about why you can't have a direct dependency on
>> log4j?
>
> Along the same lines, what issues does the jdk logger have? It
> would seem to make the most sense in terms of long term community
> support to use the jdk supported logging system.
Maybe a silly question:
Will cocoon be compatible with other Java VM?
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by peter royal <pr...@apache.org>.
On Jan 6, 2005, at 5:27 PM, Stefano Mazzocchi wrote:
>> As far as I'm concerned, Cocoon can use log4j or the JDK logger as
>> long as
>> it is done through an abstraction layer.
>
> Why can't you write a log4j appender that talks to your system?
>
> I'm not trying to be dense, I'm just trying to understand.
You don't have unified configuration then.
What we have now is very nice. I have a single logging configuration
file for my entire application. That includes the app server (phoenix)
all the way down to individual components (such as cocoon).
Having cocoon hardwired to a specific logging implementation would
loose this incredible flexibility.
-pete
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Ralph Goers wrote:
> Stefano Mazzocchi wrote:
>
>> Why can't you write a log4j appender that talks to your system?
>>
>> I'm not trying to be dense, I'm just trying to understand.
>
>
> That would mean that I would be using log4j's configuration and
> filtering. If that was what I wanted I would just write my own log4j
> appenders. To feed it into my logging framework would mean two logging
> configurations (log4j's and mine) and double the path length. If I only
> wanted my framework's filtering it would mean that all logging
> "isEnabled" calls would have to return true to the application, so they
> could be filtered by my logging framework.
>
> Not pretty.
Fair enough.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Stefano Mazzocchi wrote:
> Why can't you write a log4j appender that talks to your system?
>
> I'm not trying to be dense, I'm just trying to understand.
That would mean that I would be using log4j's configuration and
filtering. If that was what I wanted I would just write my own log4j
appenders. To feed it into my logging framework would mean two logging
configurations (log4j's and mine) and double the path length. If I only
wanted my framework's filtering it would mean that all logging
"isEnabled" calls would have to return true to the application, so they
could be filtered by my logging framework.
Not pretty.
Ralph
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Ralph Goers wrote:
> I cannot have a direct dependency on any logging implementation that does
> not let me replace it. We use our own logging framework that, believe it
> or not, is somewhat more advanced.
>
> As far as I'm concerned, Cocoon can use log4j or the JDK logger as long as
> it is done through an abstraction layer. While I am not necessarily
> thrilled with the logkit logger and its configuration, I am happy that I
> can just declare my own class that implements LoggerManager in web.xml and
> my logging framework gets used. In fact, I'd be fine if we just
> incorporated that piece from logkit into Cocoon and then had the default
> implementation use log4j or the jdk logger.
Why can't you write a log4j appender that talks to your system?
I'm not trying to be dense, I'm just trying to understand.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by peter royal <pr...@apache.org>.
On Jan 5, 2005, at 4:59 PM, Ralph Goers wrote:
> As far as I'm concerned, Cocoon can use log4j or the JDK logger as
> long as
> it is done through an abstraction layer. While I am not necessarily
> thrilled with the logkit logger and its configuration, I am happy that
> I
> can just declare my own class that implements LoggerManager in web.xml
> and
> my logging framework gets used. In fact, I'd be fine if we just
> incorporated that piece from logkit into Cocoon and then had the
> default
> implementation use log4j or the jdk logger.
+1
I have the same view. As long as cocoon's logging implementation is
pluggable, I don't care.
-pete
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
I cannot have a direct dependency on any logging implementation that does
not let me replace it. We use our own logging framework that, believe it
or not, is somewhat more advanced.
As far as I'm concerned, Cocoon can use log4j or the JDK logger as long as
it is done through an abstraction layer. While I am not necessarily
thrilled with the logkit logger and its configuration, I am happy that I
can just declare my own class that implements LoggerManager in web.xml and
my logging framework gets used. In fact, I'd be fine if we just
incorporated that piece from logkit into Cocoon and then had the default
implementation use log4j or the jdk logger.
Ralph
Stefano Mazzocchi said:
> Can you tell us more about why you can't have a direct dependency on
> log4j?
>
> --
> Stefano.
>
>
Re: [RT] Logging in 2.2
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Wed, 5 Jan 2005, Stefano Mazzocchi wrote:
> Ralph Goers wrote:
> > So far we have:
> >
> > -1 on commons-logging (from Nicola)
> > -1 on log4j (from me)
> > -1 on jdk logger (from me - same reason as log4j)
> > and it looks like -1 on UGLI from Torsten.
> >
> > That leaves logkit and just4log (which I haven't looked at). Unless
> > someone has something else?
>
> I don't want to escalate this unnecessarely, but the above should be
> treated as votes, not vetos.
>
> My point being: it might be wise not to change things too much ("if
> ain't broken don't fix it" and all that) but at the same time, it's
> getting kind of ridiculous that we are the only users of a particular API.
>
> Can you tell us more about why you can't have a direct dependency on log4j?
Along the same lines, what issues does the jdk logger have? It
would seem to make the most sense in terms of long term community
support to use the jdk supported logging system.
--
JP
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Ralph Goers wrote:
> So far we have:
>
> -1 on commons-logging (from Nicola)
> -1 on log4j (from me)
> -1 on jdk logger (from me - same reason as log4j)
> and it looks like -1 on UGLI from Torsten.
>
> That leaves logkit and just4log (which I haven't looked at). Unless
> someone has something else?
I don't want to escalate this unnecessarely, but the above should be
treated as votes, not vetos.
My point being: it might be wise not to change things too much ("if
ain't broken don't fix it" and all that) but at the same time, it's
getting kind of ridiculous that we are the only users of a particular API.
Can you tell us more about why you can't have a direct dependency on log4j?
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
So far we have:
-1 on commons-logging (from Nicola)
-1 on log4j (from me)
-1 on jdk logger (from me - same reason as log4j)
and it looks like -1 on UGLI from Torsten.
That leaves logkit and just4log (which I haven't looked at). Unless
someone has something else?
Torsten Curdt said:
> Torsten Curdt wrote:
>>> How UGLI manage the case when a parameter is a function, ie:
>>
>>
>> ...some more: Marcus and I were curious how UGLI will work.
>>
>> So well believe it or not - UGLI only supports a max of *2*
>> parameters! Since java does not support variable parameter
>> lists something like that was no big surprise.
>
> ...talking about 1.4 - of course.
>
> I doubt someone wants raise the bar to 1.5 yet ;-)
> --
> Torsten
>
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
Torsten Curdt wrote:
>> How UGLI manage the case when a parameter is a function, ie:
>
>
> ...some more: Marcus and I were curious how UGLI will work.
>
> So well believe it or not - UGLI only supports a max of *2*
> parameters! Since java does not support variable parameter
> lists something like that was no big surprise.
...talking about 1.4 - of course.
I doubt someone wants raise the bar to 1.5 yet ;-)
--
Torsten
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
> How UGLI manage the case when a parameter is a function, ie:
...some more: Marcus and I were curious how UGLI will work.
So well believe it or not - UGLI only supports a max of *2*
parameters! Since java does not support variable parameter
lists something like that was no big surprise.
In order not to provide an unlimited number of combinations
on the interface primitive types are not supported by UGLI
as well.
Not sure if we missed something ...but so far UGLY ..ups
UGLI does not look very promising to me.
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 11:19, Nicola Ken Barozzi dijo:
> Antonio Gallardo wrote:
> ...
>> Please have a look at the Torsten suggestions, looks good too:
>>
>> http://just4log.sourceforge.net
>>
>> +1 too.
>
> I saw that too, but UGLI should not need that extra isLogEnabled stuff
> in any case.
>
> BTW, I love the way this makes one write log messages, it's what we have
> in POI, and is very convenient.
>
> Ceki wrote:
> "
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string
> ["+query"]." );
> }
>
> you can just write:
>
> logger.debug("User with {} entered wrong query string [{}].", id,
> query);
> "
How UGLI manage the case when a parameter is a function, ie:
logger.debug("User with {} entered wrong query string [{}].", myFunction(),
myQuery());
Well, we know what happen here: The functions are executed to retrieve the
return value. AFAIK, this is why we use isDebugEnable()? And here is where
"just4log" play an important role. ;-)
WDYT?
Best Regards,
Antonio Gallardo
Re: [RT] Logging in 2.2
Posted by Torsten Curdt <tc...@apache.org>.
>> logger.debug("User with {} entered wrong query string [{}].", id,
>> query);
>> "
>
>
> very pythonish. I like it :-)
...but only with jdk 1.5 :-/
cheers
--
Torsten
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> On Wed, 05 Jan 2005 15:42:08 -0500, Stefano Mazzocchi
> <st...@apache.org> wrote:
>
>>Nicola Ken Barozzi wrote:
>>
>>>Antonio Gallardo wrote:
>
>
>>>I saw that too, but UGLI should not need that extra isLogEnabled stuff
>>>in any case.
>
>
> How so? What am I missing?
>
>
>>>As noted in my previous message, UGLI also supports parameterized log
>>>messages obliterating the need to surround log messages with
>>>logger.isXXXEnabled checks.
>>>
>>>Instead of writing:
>>>
>>> if(logger.isDebugEnabled()) {
>>> logger.debug("User with "+id+" entered wrong query string
>>>["+query"]." );
>>> }
>>>
>>>you can just write:
>>>
>>> logger.debug("User with {} entered wrong query string [{}].", id,
>>>query);
>>>"
>>
>>very pythonish. I like it :-)
>>
>>-1 on just4log then.
>
>
> I'm probably not getting the point. This solves the string
> concatenation issue (which, besides and AFAIU, today is quite a bit
> faster than it used to be in older JVMs), but isn't necessarily, and
> per se, a permanent solution. Since this is an interface (and quite
> an ugly one given the two parameter limitation... what's wrong with a
> logger.xxx(String message, String[] params) as an alternative?), you
> don't know if the current implementation just tokenizes the message
> and performs concatenation anyway. Moreover, this is no solution to
> logger.debug("my {} message", runMeAndIllKillYourMachine()) which
> still would need to be wrapped...
right, forget what I said.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Wed, 05 Jan 2005 15:42:08 -0500, Stefano Mazzocchi
<st...@apache.org> wrote:
> Nicola Ken Barozzi wrote:
> > Antonio Gallardo wrote:
> > I saw that too, but UGLI should not need that extra isLogEnabled stuff
> > in any case.
How so? What am I missing?
> > As noted in my previous message, UGLI also supports parameterized log
> > messages obliterating the need to surround log messages with
> > logger.isXXXEnabled checks.
> >
> > Instead of writing:
> >
> > if(logger.isDebugEnabled()) {
> > logger.debug("User with "+id+" entered wrong query string
> > ["+query"]." );
> > }
> >
> > you can just write:
> >
> > logger.debug("User with {} entered wrong query string [{}].", id,
> > query);
> > "
>
> very pythonish. I like it :-)
>
> -1 on just4log then.
I'm probably not getting the point. This solves the string
concatenation issue (which, besides and AFAIU, today is quite a bit
faster than it used to be in older JVMs), but isn't necessarily, and
per se, a permanent solution. Since this is an interface (and quite
an ugly one given the two parameter limitation... what's wrong with a
logger.xxx(String message, String[] params) as an alternative?), you
don't know if the current implementation just tokenizes the message
and performs concatenation anyway. Moreover, this is no solution to
logger.debug("my {} message", runMeAndIllKillYourMachine()) which
still would need to be wrapped...
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
Re: [RT] Logging in 2.2
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Antonio Gallardo wrote:
> ...
>
>> Please have a look at the Torsten suggestions, looks good too:
>>
>> http://just4log.sourceforge.net
>>
>> +1 too.
>
>
> I saw that too, but UGLI should not need that extra isLogEnabled stuff
> in any case.
>
> BTW, I love the way this makes one write log messages, it's what we have
> in POI, and is very convenient.
>
> Ceki wrote:
> "
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string
> ["+query"]." );
> }
>
> you can just write:
>
> logger.debug("User with {} entered wrong query string [{}].", id,
> query);
> "
very pythonish. I like it :-)
-1 on just4log then.
--
Stefano.
Re: [RT] Logging in 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Nicola Ken Barozzi wrote:
> I saw that too, but UGLI should not need that extra isLogEnabled stuff
> in any case.
>
> BTW, I love the way this makes one write log messages, it's what we
> have in POI, and is very convenient.
>
> Ceki wrote:
> "
> As noted in my previous message, UGLI also supports parameterized log
> messages obliterating the need to surround log messages with
> logger.isXXXEnabled checks.
>
> Instead of writing:
>
> if(logger.isDebugEnabled()) {
> logger.debug("User with "+id+" entered wrong query string
> ["+query"]." );
> }
>
> you can just write:
>
> logger.debug("User with {} entered wrong query string [{}].", id,
> query);
IMO, this is bad syntactic sugar, as it may lead people to forget that
parameters have to be evaluated too. Consider this:
Source src = resolver.resolveURI("http://slow.server.com/");
logger.debug("Length is {} bytes", src.getLength());
An http request on each run, even if debug is disabled!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Logging in 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Antonio Gallardo wrote:
...
> Please have a look at the Torsten suggestions, looks good too:
>
> http://just4log.sourceforge.net
>
> +1 too.
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love the way this makes one write log messages, it's what we have
in POI, and is very convenient.
Ceki wrote:
"
As noted in my previous message, UGLI also supports parameterized log
messages obliterating the need to surround log messages with
logger.isXXXEnabled checks.
Instead of writing:
if(logger.isDebugEnabled()) {
logger.debug("User with "+id+" entered wrong query string
["+query"]." );
}
you can just write:
logger.debug("User with {} entered wrong query string [{}].", id,
query);
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Logging in 2.2
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 5 de Enero de 2005, 10:13, Nicola Ken Barozzi dijo:
> Carsten Ziegeler wrote:
> ...
>> So my plan would be:
>> 1. Decide for one logging api (log4j or commons-logging)
OK. You convinced me. ;-)
-1 for commons-logging
-0 for log4j
+0 for JDK logging (less dependencies)
+1 for UGLI
OK. You convinced me. ;-)
Please have a look at the Torsten suggestions, looks good too:
http://just4log.sourceforge.net
+1 too.
Best Regards,
Antonio Gallardo.
Re: [RT] Logging in 2.2
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 05/gen/05, alle 17:13, Nicola Ken Barozzi ha scritto:
> -1 for commons-logging
> -0 for log4j
> +0 for JDK logging (less dependencies)
> +1 for UGLI
>
> I've suffered too much with commons-logging configuration to be able
> to like it in any way.
OK, you convinced me. +1 for UGLI :-)
Ugo
--
Ugo Cei - http://beblogging.com/blojsom/blog/
Re: [RT] Logging in 2.2
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
...
> So my plan would be:
> 1. Decide for one logging api (log4j or commons-logging)
-1 for commons-logging
-0 for log4j
+0 for JDK logging (less dependencies)
+1 for UGLI
I've suffered too much with commons-logging configuration to be able to
like it in any way.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------