From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
> Henri Yandell wrote, On 06/02/2003 11.18:
> >
> > On Thu, 6 Feb 2003, Henri Yandell wrote:
> >
> >>On Thu, 6 Feb 2003, Nicola Ken Barozzi wrote:
> >>
> >>>One point that we would like to see is that commons logging is never a
> >>>*hard* dependency. That means that if commons logging is not in the
> >>>classpath, the package should be able to work correctly, even if with
> >>>logging disabled.
> >>
> >>Please justify this. Is it solely because you have people who refuse to
go
> >>near commons-logging, or is there a technical reason?
> >
> >
> > I'm just funked. Ignore this.
>
> Naa, you are right, I have to justify it.
>
> The fact is that Commons Logging does not advocate IOC, Inversion of
> Control, that is so dear to us.
I know this is probably gonna end up a pointless religious debate or
flamefest but I couldn't resist...
I see no reason why someone can't use Commons Logging in an IOC pattern if
thats what they want to do. It boils down to a framework/religious issue
rather than anything fundamentally wrong with commons logging.
e.g.
import org.apache.commons.logging.Log;
public class SomeService {
// container sets the logger to be used using IOC
public void setLog(Log log);
}
Whether there's an explicit LogEnabled marker interface or bean
introspection is used (I prefer the latter) makes little difference - its
still IOC isn't it? Unless IOC is only IOC with explicit marker interfaces?
Comparing commons logger and the logkit in Avalon Framework (and ignoring
their history for now) - they now look practically identical apart from the
LogEnabled interface (which isn't really needed anyway though I'm sure if it
was essential to Avalon users there wouldn't be much resistence to adding
something like this to commons-logging).
Indeed there's nothing to stop someone using logkit in Avalon Framework in a
non-IOC way.
public class SomeBean {
private Logger log = new ConsoleLogger();
...
}
So objecting about commons-logging not advocating IOC doesn't seem to make
sense. It'd be trivial to write a commons Log implementation that uses
logkit if you're really concerned about logging integration - though for
command line tools I'm not sure its worth it.
Isn't it about time we merged logkit into commons logging?
(ducks religious war)
> And also that IMHO these small packages
> should not log by default, since logging in these cases is not a runtime
> requirement as in server applications but a debugging and development
> requirement.
Why would a command line application thats using commons-logging be
concerned about the IOC of the logger thats used by the main()? I can see
this pro-logkit argument applying to other reusable components, but one
thats tied to a command line tool (and so a stand alone application by
definition) seems a bit of a leap.
> It's ok if it uses Commons Logging, as long as it's not a hard
> dependency. I think it's a good common ground, and it's what is done ATM.
>
> I have personally committed Commons Logging in POI, and made it not
> break the usage of the jar if not present, so should make it clear what
> I think of the usage of Commons Logging in the scenario of reusable
> components.
How did you do that? By writing yet another logging abstraction? :-)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
