You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/02/08 02:21:40 UTC
Re: [logging] To depend or not to depend?
Hi peeps,
jumping in a little late here I guess....I'm going to mostly rant about
how avalon relates to (and could in the future) commons-logging and
logging in general, and not about the general case, as I feel I don't
have enough knowledge to talk about the general case.
Summary
=======
warning: terribly long-winded! :D
We are also looking at how to integrate logkit & log4j; good hopes too
but (personal estimate) it will take lots of time and effort.
We are looking at how to integrate commons-logging into avalon; it looks
promising. We cannot drop stuff like the Logger interface in
avalon-framework because we need backwards compatibility.
It seems like a commons-logging-noop.jar would make the difficulty of
integrating a commons-logging-using-library into an avalon container and
similar projects mostly dissapear.
(I also take too much time to explain the current logging setup in the
various parts of avalon)
Logging in Avalon
=================
Introduction
------------
There's three main logging-related packages over @ avalon. There's
avalon-logkit, which is a seperate downloadable binary that has got no
dependency on any other part of avalon, and vice versa other parts of
avalon have mostly been modified to have no more than soft dependencies
on avalon-logkit.
The avalon-logkit feature set and use case is about the same as for
log4j (differences are becoming less and less with each release).
There's excalibur-logger, which is mostly utility code for use by avalon
containers to handle their logging setup. It is distributed as part of
phoenix, ECM, and also included in the old big releases of excalibur.
This is sort-of avalon-internal utility code.
Then there's avalon-framework, the client API which avalon components
talk to in order to handle their logging. There's a package
org.apache.avalon.framework.logger, with the avalon lifecycle interface
LogEnabled, into which is passed an implementation of Logger. There's
implementations of that Logger interface using the console, logkit,
log4j and jdk14 logging.
This package is very similar to commons-logging in that it provides a
sort-of facade to an underlying logging implementation.
Logkit & Log4J
--------------
There's been talks for ages about increased synergy between these
projects, and recently people have been getting more enthousiastic
again. It's doable. Hopefully we'll get there sometime. Lack of time and
the need to support an existing userbase will mean this kind of process
will probably take lots of time. And, I personally find this kind of
stuff a terribly unsexy task ;)
(sidenote: I think it makes as little sense to integrate logkit into
commons-logging as it makes sense to integrate log4j into
commons-logging, ie very little. Commons-logging should not provide a
logging implementation IMHO.)
Avalon-Framework & Commons-Logging
----------------------------------
We used to have (still have, deprecated) a Loggable interface which was
coupled to Logkit, ie:
public interface Loggable {
void setLogger( org.apache.log.Logger logger ); }
this was cumbersome as lots of people wanted to use log4j with avalon
for obvious reasons, hence we now have LogEnabled and a simple facade.
Looking at the similarity between the Logger interface in
avalon-framework and the Logger interface in commons-logging it is
obvious that it makes sense to remove one in place of the other. It does
not make sense to have a dependency on avalon-framework for commons-logging.
While it can make sense to have a dependency on commons-logging for
avalon-framework, we are not going to change the LogEnabled interface
(in avalon-framework 4.x) because we need total binary compatibility. As
such, we also need to keep supporting the Logger interface in
avalon-framework.
What is probably perfectly doable is providing:
--------------------------------
package org.apache.avalon.framework;
public class CommonsLoggingLogger implements Logger
{
private Log m_log;
public CommonsLoggingLogger(
org.apache.commons.loggging.Log log )
{ m_log = log; }
void debug( String message ) { m_log.debug( message ); }
// simply redirect all methods defined in Logger to Log
}
--------------------------------
this is on the TODO. Not for an upcoming avalon-framework 4.1.4, but it
might very well be in 4.1.5.
Excalibur-Logger & Commons-Logging
----------------------------------
Avalon containers like Avalon-Phoenix provide a very rigid black-box to
hosted components, and provide support for complex multi-classloader
setups. Very similar tech and associated problems as in EJB and servlet
containers.
Within such a setup, the static factory pattern can often lead to nasty
problems most of y'all probably have more experience with than me. We're
very cautious with promoting use of libraries in avalon client code
which enable use of static factories (the use of static factories within
an avalon-container itself is less of an issue, as using IoC means the
container behaviour in such a situation can be deterministic, but as a
matter of habit, preference, and example, avalon containers are pretty
non-static as well).
These containers defer to excalibur-logger for handling most of their
logging needs. Excalibur-logger contains an interface LoggerManager,
which does mostly the same as commons-logging its LogFactory, with the
main difference it is completely non-static in nature. LoggerManager
also needs to stay around for ages in order to preserve backwards
compatibility.
Again, it should be possible to write a CommonsLoggerManager which
defers to a LogFactory:
--------------------------------
package org.apache.avalon.excalibur.logger;
public class CommonsLoggerManager implements LoggerManager
{
private org.apache.commons.LogFactory m_factory;
public CommonsLoggingLogger(
org.apache.commons.loggging.LogFactory factory )
{ m_factory = factory; }
Logger getLoggerForCategory( String name )
{
return new CommonsLoggingLogger( m_factory.getInstance(name) );
}
// simply redirect all methods defined in LoggerManager
// to LogFactory
}
--------------------------------
investigating this and how well it works is also on the TODO. I believe
Jason's already done a lot of work in this direction with plexus, but I
haven't actually looked at it yet.
Logging in libraries used by Avalon
===================================
The dillema/problem
-------------------
Stuff like commons-collections, commons-cli and commons-lang and all
those other libraries I don't know much about just yet can definately be
put to use in avalon all over the place. Our goal is indeed to get the
'utility code' in avalon 'out' (and donate it to another project or
deprecate it if a better alternative supporting the full usecase already
exists, like with cli), and use the common code as much as possible.
In avalon containers like Avalon-Phoenix, we need to provide the end
user with control over how to do logging. If a library does something like
class MyToolLikeCLI
{
private static Log log = LogFactoryImpl.getInstance("");
doStuff()
{
try { /* ... */ } catch( Throwable t )
{ log.error( "no good" ); }
}
}
that makes our job a lot harder. Hence
<dependency><id>commons-logging</id></dependency>
triggers a warning sign when evaluating how easy it is to integrate a
library, as 'LogFactoryImpl.getInstance("")' looks like a lot of work to
circumvent cleanly, and it is I believe commonly used.
Note that I totally agree the code in avalon creates a lot of the same
problem with possibility for stuff like
private static Logger log = new ConsoleLogger()
The only difference is that such a setup is discouraged in avalon and
not in commons-logging. It'd be nice if the commons-logging docs would
as well or at least point out potential problems (says nosy me, not
actually knowing whether they do).
Personal preferences 'n stuff
-----------------------------
I like a library that doesn't use anything with a 'static' keyword
attached to any of its methods that actually do much. It just makes life
easier in the classloader-hell world we have in java. I would like the
commons libraries to use a similar setup to Digester's setLogger() as
much as possible.
Possible solution/workaround
----------------------------
Now, I saw someone suggest this problem is avoidable, ie by putting in
place an alternative implementation for commons-logging which intercepts
stuff like getInstance(), perhaps always providing a NoOpLog. This
sounds like a workable, easily implementable idea, even if it feels
'hacky'. IIUC what would happen is we put in place
commons-logging-noop.jar (commons-stub.jar)
commons-cli.jar
commons-lang.jar
commons-(...).jar
and never again get anxious about
<dependency><id>commons-logging</id></dependency>
Sounds like a plan, and probably a rather common need for many projects,
not just avalon. Maybe some smart classloader hacker/proxy wizard can
even create something that properly routes LogFactory calls back into an
excalibur LoggerManager...but I see a bigger amount of work and
complexity involved there.
hope this all made some kind of sense to someone somewhere.
cheers & g'night,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [logging] To depend or not to depend?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> Possible solution/workaround
> ----------------------------
> Now, I saw someone suggest this problem is avoidable, ie by putting in
> place an alternative implementation for commons-logging which intercepts
> stuff like getInstance(), perhaps always providing a NoOpLog. This
> sounds like a workable, easily implementable idea, even if it feels
> 'hacky'. IIUC what would happen is we put in place
>
> commons-logging-noop.jar (commons-stub.jar)
> commons-cli.jar
> commons-lang.jar
> commons-(...).jar
>
> and never again get anxious about
>
> <dependency><id>commons-logging</id></dependency>
FYI, commons-lang and commons-collections do not depened on [logging], nor
are they likely to do so. ([lang]s charter pretty much excludes it for
example)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [logging] To depend or not to depend?
Posted by Leo Simons <le...@apache.org>.
robert burrell donkin wrote:
> On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
>
>> James Strachan wrote:
>>
>>> Would it be acceptable
>>>
>>>> to add a getName() or something similar to the Log interface and the
>>>> implementations? That way, we can fully implement the avalon-framework
>>>> Logger contract on top of commons-logging.
>>>
>>> +1.
>>> Seems reasonable to me. I guess it won't break anyones code who just use
>>> commons-logging to log. The only risk is people who implement Log,
>>
>> yep. It is a backwards-incompatible change there.
>
> losing backward compatibility seems to me like it might open up a whole
> can of worms. i worry that here in the commons we'd be left with major
> incompatible problems between components based on the version of
> commons-logging that they used.
>
> a lot of time and debate was spent on the Log interface. as far as the
> original idea is concerned, it's exactly right the way it is. once we
> start changing the original concept, when do we stop?
>
> rather than dive in and make changes to something which took literally
> months of debate to get right (ie the Log interface), i'd prefer it if
> we could look around for a solution which would preserve backwards
> compatibility for this critical interface.
>
> wouldn't it be better to either extend Log or create a Logger class
> which implements Log but which has the extra method(s) that leo needs?
The problem is precisely in implementing such a Logger; you need the
right logger name in order to do something requiring that name. The
obvious change is to change the constructor signature to
CommonsLogger( Log log, String name ) { ... }
I need to do some thinking on the impact this has on code that needs to
create the loggers. Obviously, the avalon-framework Logger has a teeny
weeny little bit of information exposed which Log doesn't expose, and
there is no optimal route around it.
I think the new constructor is more acceptable than the change to Log,
meaning the additional method is unneccessary. The silly part is that
the logging name is known inside all the things Log abstracts away from,
yet not available through the interface. No API is ever perfect :D
Regardless, I think adding an additional base class or interface which
does provide the extra information is not a good idea: you keep the same
problem where components will depend on the new release with the new
interface in it.
ah, the wonderful world of spending hours deciding on a single method :D
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by Leo Simons <le...@apache.org>.
Hi peeps,
Leo Simons wrote:
>> Would it be acceptable
>>> to add a getName() or something similar to the Log interface and the
>>> implementations?
<snip/>
> It is a backwards-incompatible change
tried a few things here, and I think the answer to my own question is a
definitive "no": it breaks backwards (binary) compatibility across
jakarta commons, and who knows where else. It is potentially disastrous
for projects that provide their own implementation of the Log interface.
Consider, for example, a log implementation where no name is ever
associated with a category. It's a change-of-contract, indeed.
I think all alternatives mentioned within the boundary of
commons-logging are also not very good moves, like adding a NamedLog,
which will add to jar size, probably will not be used in many apps, and
moreover breaks the entire *single interface* paradigm -- the main
reason (yep, assumption here ;) that commons-logging exists.
Also, one can safely assume that in true IoC (ie avalon), the thing (ie
the container) that sets up the logging also has the information as to
how the logging is to be named, and hence can pass this in to an avalon
CommonsLogger on creation.
Got up to speed on some new tech this weekend, and lo and behold, plexus
already has a CommonsLogger which does exactly that:
http://tambora.zenplex.org/cgi-bin/viewcvs.cgi/plexus/src/java/org/apache/plexus/logging/commons/CommonsLogger.java
ain't that cool :D
We had some discussion over @ avalon on including a CommonsLogger class
in 4.1.4, but it didn't make it (we need to remove some logging-related
confusion ;). Subject will be raised again for 4.1.5, or maybe
CommonsLogger goes into a utility library.
Last thing I took away from this thread is that I do think a
commons-noop-logging.jar is a common need for those times when you don't
want logging, or at least don't want a dependency. I'll send in a patch
if it ever does become enough of an itch :D
anyway, thanks for all your feedback!
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by Costin Manolache <cm...@yahoo.com>.
James Strachan wrote:
> Maybe using introspection on the Log implementation might be easier to add
> incrementally to Log implementations without breaking backwards
> compatibility.
Introspection or JMX ( which is the other name for introspection :-).
Each LogFactory or Log can support a lot of features in a backward
compatible way by using JMX. There is absolutely no reason to change the
Log interface - it does what it should do. Adding another interface may be
a solution - but I don't think it is needed in most cases - and certainly
not for management operations.
Costin
>
>> Adding a new method might be OK in a 2.x release (although I don't feel a
>> particular compulsion towards it), but would be against the spirit of
>> Commons support for backwards compatibility in a 1.x releaese; so I'd
>> definitely be -1 there.
>
> So you might not be -1 if if it were a 2.x release change?
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Craig R. McClanahan" <cr...@apache.org>
> On Mon, 10 Feb 2003, James Strachan wrote:
> > Maybe we could introduce a seperate interface, NamedLog which has a
single
> > getName() method? Or just use introspection and add a getName() method
to
> > the core Log implementations? Though both of these increase the size
and/or
> > complexity of commons-logging, so I'd personally prefer just adding a
new
> > method to Log; its a fairly minor change.
> >
>
> NamedLog wouldn't help the stated Avalon use case, because there would
> still be existing libraries that don't use it. Convincing the world to
> change would not be a likely scenario.
But the default Log implementations in commons-logging could implement
NamedLog and then Avalon could check for it and if not just log a warning &
use a default value?
Maybe using introspection on the Log implementation might be easier to add
incrementally to Log implementations without breaking backwards
compatibility.
> Adding a new method might be OK in a 2.x release (although I don't feel a
> particular compulsion towards it), but would be against the spirit of
> Commons support for backwards compatibility in a 1.x releaese; so I'd
> definitely be -1 there.
So you might not be -1 if if it were a 2.x release change?
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 10 Feb 2003, James Strachan wrote:
> Date: Mon, 10 Feb 2003 08:24:39 -0000
> From: James Strachan <ja...@yahoo.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [logging] To depend or not to depend?
>
> From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> > On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
> >
> > > James Strachan wrote:
> > >> Would it be acceptable
> > >>> to add a getName() or something similar to the Log interface and the
> > >>> implementations? That way, we can fully implement the avalon-framework
> > >>> Logger contract on top of commons-logging.
> > >> +1.
> > >> Seems reasonable to me. I guess it won't break anyones code who just
> use
> > >> commons-logging to log. The only risk is people who implement Log,
> > >
> > > yep. It is a backwards-incompatible change there.
> >
> > losing backward compatibility seems to me like it might open up a whole
> > can of worms. i worry that here in the commons we'd be left with major
> > incompatible problems between components based on the version of
> > commons-logging that they used.
> >
> > a lot of time and debate was spent on the Log interface. as far as the
> > original idea is concerned, it's exactly right the way it is. once we
> > start changing the original concept, when do we stop?
> >
> > rather than dive in and make changes to something which took literally
> > months of debate to get right (ie the Log interface), i'd prefer it if we
> > could look around for a solution which would preserve backwards
> > compatibility for this critical interface.
> >
> > wouldn't it be better to either extend Log or create a Logger class which
> > implements Log but which has the extra method(s) that leo needs?
>
> I hear you - though this change would maintain backwards compatibility for
> people who use Log, it would just break Log implementations. I wonder how
> many people have developed custom Log implementations?
>
A lot more than you might expect.
Large scale applications that want to take advantage of the flexibility
inherent in the current design will often implement Log and LogFactory in
a glue layer to adapt libraries using commons-logging into an existing
architecture.
> Maybe we could introduce a seperate interface, NamedLog which has a single
> getName() method? Or just use introspection and add a getName() method to
> the core Log implementations? Though both of these increase the size and/or
> complexity of commons-logging, so I'd personally prefer just adding a new
> method to Log; its a fairly minor change.
>
NamedLog wouldn't help the stated Avalon use case, because there would
still be existing libraries that don't use it. Convincing the world to
change would not be a likely scenario.
Adding a new method might be OK in a 2.x release (although I don't feel a
particular compulsion towards it), but would be against the spirit of
Commons support for backwards compatibility in a 1.x releaese; so I'd
definitely be -1 there.
> James
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
>
> > James Strachan wrote:
> >> Would it be acceptable
> >>> to add a getName() or something similar to the Log interface and the
> >>> implementations? That way, we can fully implement the avalon-framework
> >>> Logger contract on top of commons-logging.
> >> +1.
> >> Seems reasonable to me. I guess it won't break anyones code who just
use
> >> commons-logging to log. The only risk is people who implement Log,
> >
> > yep. It is a backwards-incompatible change there.
>
> losing backward compatibility seems to me like it might open up a whole
> can of worms. i worry that here in the commons we'd be left with major
> incompatible problems between components based on the version of
> commons-logging that they used.
>
> a lot of time and debate was spent on the Log interface. as far as the
> original idea is concerned, it's exactly right the way it is. once we
> start changing the original concept, when do we stop?
>
> rather than dive in and make changes to something which took literally
> months of debate to get right (ie the Log interface), i'd prefer it if we
> could look around for a solution which would preserve backwards
> compatibility for this critical interface.
>
> wouldn't it be better to either extend Log or create a Logger class which
> implements Log but which has the extra method(s) that leo needs?
I hear you - though this change would maintain backwards compatibility for
people who use Log, it would just break Log implementations. I wonder how
many people have developed custom Log implementations?
Maybe we could introduce a seperate interface, NamedLog which has a single
getName() method? Or just use introspection and add a getName() method to
the core Log implementations? Though both of these increase the size and/or
complexity of commons-logging, so I'd personally prefer just adding a new
method to Log; its a fairly minor change.
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:
> James Strachan wrote:
>> Would it be acceptable
>>> to add a getName() or something similar to the Log interface and the
>>> implementations? That way, we can fully implement the avalon-framework
>>> Logger contract on top of commons-logging.
>> +1.
>> Seems reasonable to me. I guess it won't break anyones code who just use
>> commons-logging to log. The only risk is people who implement Log,
>
> yep. It is a backwards-incompatible change there.
losing backward compatibility seems to me like it might open up a whole
can of worms. i worry that here in the commons we'd be left with major
incompatible problems between components based on the version of
commons-logging that they used.
a lot of time and debate was spent on the Log interface. as far as the
original idea is concerned, it's exactly right the way it is. once we
start changing the original concept, when do we stop?
rather than dive in and make changes to something which took literally
months of debate to get right (ie the Log interface), i'd prefer it if we
could look around for a solution which would preserve backwards
compatibility for this critical interface.
wouldn't it be better to either extend Log or create a Logger class which
implements Log but which has the extra method(s) that leo needs?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by Leo Simons <le...@apache.org>.
James Strachan wrote:
> Would it be acceptable
>>to add a getName() or something similar to the Log interface and the
>>implementations? That way, we can fully implement the avalon-framework
>>Logger contract on top of commons-logging.
>
> +1.
>
> Seems reasonable to me. I guess it won't break anyones code who just use
> commons-logging to log. The only risk is people who implement Log,
yep. It is a backwards-incompatible change there.
> but since
> most of the implementations are inside commons-logging, it doesn't seem too
> bad.
yep.
> BTW did you mean to CC dev@httpd.apache.org or did you mean avalon-dev? :)
the latter of course. Silly me :D
I've attached a patch which adds a 'public String getName()' method to
Log and all implementations (relative to jakarta-commons/logging).
cheers,
- Leo
Re: [logging] To depend or not to depend?
Posted by bob mcwhirter <bo...@werken.com>.
> > as [current-loggers-name] is not exposed by Log. Would it be acceptable
> > to add a getName() or something similar to the Log interface and the
> > implementations? That way, we can fully implement the avalon-framework
> > Logger contract on top of commons-logging.
>
> +1.
>
> Seems reasonable to me. I guess it won't break anyones code who just use
> commons-logging to log. The only risk is people who implement Log, but since
> most of the implementations are inside commons-logging, it doesn't seem too
> bad.
+1 definitely.
-bob
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Leo Simons" <le...@apache.org>
> Leo Simons wrote:
> > What is probably perfectly doable is providing:
> > --------------------------------
> > package org.apache.avalon.framework;
> >
> > public class CommonsLoggingLogger implements Logger
> <snip/>
> > --------------------------------
> >
> > this is on the TODO. Not for an upcoming avalon-framework 4.1.4, but it
> > might very well be in 4.1.5.
>
> okay, so I took a closer look and just implemented this as it's real
> easy to do. I actually did
>
> public final class CommonsLogger implements Logger, Log { /* ... */ }
>
> as that makes life even easier on component developers. One method
> causes problems:
>
> interface Logger
> {
> /**
> * Create a new child logger.
> * The name of the child logger is
> [current-loggers-name].[passed-in-name]
> * Throws <code>IllegalArgumentException</code> if name has an
> empty element name
> *
> * @param name the subname of this logger
> * @return the new logger
> */
> Logger getChildLogger( String name );
> }
>
> as [current-loggers-name] is not exposed by Log. Would it be acceptable
> to add a getName() or something similar to the Log interface and the
> implementations? That way, we can fully implement the avalon-framework
> Logger contract on top of commons-logging.
+1.
Seems reasonable to me. I guess it won't break anyones code who just use
commons-logging to log. The only risk is people who implement Log, but since
most of the implementations are inside commons-logging, it doesn't seem too
bad.
BTW did you mean to CC dev@httpd.apache.org or did you mean avalon-dev? :)
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> What is probably perfectly doable is providing:
> --------------------------------
> package org.apache.avalon.framework;
>
> public class CommonsLoggingLogger implements Logger
<snip/>
> --------------------------------
>
> this is on the TODO. Not for an upcoming avalon-framework 4.1.4, but it
> might very well be in 4.1.5.
okay, so I took a closer look and just implemented this as it's real
easy to do. I actually did
public final class CommonsLogger implements Logger, Log { /* ... */ }
as that makes life even easier on component developers. One method
causes problems:
interface Logger
{
/**
* Create a new child logger.
* The name of the child logger is
[current-loggers-name].[passed-in-name]
* Throws <code>IllegalArgumentException</code> if name has an
empty element name
*
* @param name the subname of this logger
* @return the new logger
*/
Logger getChildLogger( String name );
}
as [current-loggers-name] is not exposed by Log. Would it be acceptable
to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] To depend or not to depend?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, February 8, 2003, at 01:21 AM, Leo Simons wrote:
<snip>
> Personal preferences 'n stuff
> -----------------------------
> I like a library that doesn't use anything with a 'static' keyword
> attached to any of its methods that actually do much. It just makes life
> easier in the classloader-hell world we have in java. I would like the
> commons libraries to use a similar setup to Digester's setLogger() as
> much as possible.
>
> Possible solution/workaround
> ----------------------------
> Now, I saw someone suggest this problem is avoidable, ie by putting in
> place an alternative implementation for commons-logging which intercepts
> stuff like getInstance(), perhaps always providing a NoOpLog. This sounds
> like a workable, easily implementable idea, even if it feels 'hacky'.
> IIUC what would happen is we put in place
>
> commons-logging-noop.jar (commons-stub.jar)
> commons-cli.jar
> commons-lang.jar
> commons-(...).jar
>
> and never again get anxious about
>
> <dependency><id>commons-logging</id></dependency>
>
> Sounds like a plan, and probably a rather common need for many projects,
> not just avalon.
i started wondering whether something like this would be possible without
actually having to create a dummy implementation. when the current code
fails to create a LogFactoryImpl instance, it throws a runtime exception.
this could be changed so that the exception is caught and a factory which
return no-op logs returned instead.
then if a minimal jar (excluding all the implementations) only was present,
you'd get the no-op behaviour required.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org