Re: [CLI] new design possibly?

[Nicola Ken Barozzi]

I've snipped quite some stuff, trying to remain focused.

James Strachan wrote, On 06/02/2003 16.42:

From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>

James Strachan wrote, On 06/02/2003 12.32:

...

 digester uses an IOC approach to logging, take a look at the
setLogger(Log) method

http://jakarta.apache.org/commons/digester/api/org/apache/commons/digester/D
igester.html

Cool.

It also logs to another log that cannot be set in this fashion though, and it gets it from the static method if it's not set.

Every single package in Commons that uses CL uses the static accessor.

Lots of them use setter methods too. Using the static accessor is a handy
default when not using a full blown container to deploy beans in.

What you say is correct, and I would like it to be a possible method to
enable logging to the component.

It is possible - see digester. Despite using commons logging, all commons
components could provide a mechanism for setting the Log and so implement
IOC.

Good, can we make this a recomendation?

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?

It's clear to me that you haven't looked at LogEnabled. It's not a
marker interface.

I had looked very carefully. Sure its a non-empty interface (so I guess I
shouldn't have called it a marker interface) - however its only got one
method, which is not that useful - bean introspection could be used instead.
Afterall in IOC this would be invoked by a container which could easily
figure this out without this LogEnabled interface.

Yes it could. Anything can be done, but it just happened that for Avalon4 we took this design decision. These are for Avalon5.

/**
 * Components that need to log can implement this interface to
 * be provided Loggers.
 *
 * @author Avalon Development Team
 */
public interface LogEnabled
{
    /**
     * Provide component with a logger.
     *
     * @param logger the logger. Must not be <code>null</code>.
     */
    void enableLogging( Logger logger );
}

which could just be replaced by

    void setLogger(Log);

on any bean such as with Digester - no need for this interface for IOC.

There is (...was) a need when this is part of a lifecycle specification that defines that the lifecycle phases are defined by these interfaces. At that time, we also had the Component marker interface. Now we are moving to a different view, that of metadata not encoded in interfaces. But again, that's Avalon5.

...

Let me try to explain. LogEnabled is *not* part of Logkit. LogEnabled is
part of the Avalon Framework. The avalon framework can log to multiple
implementations.

Logkit is a logging implementation, that had it's reason to be at a
point in history. Now it makes less sense, and we are discussing about
what to do. But that's another thing.

OK. I frequently get confused by Avalon -  my mistake.

Can I dare say "our" mistake ;-)

Avalon tried to be everything to everybody, by keeping implementations that we didn't really need... well it was also because of miscomunication.
Now we are reorganizing on our core assets, spinning off non-Avalon stuff, and making it much clearer for all. avalon.apache.org is the first visible baby-step in that direction.

Back on track: yes, it can make sense to evaluate Commons Logging as a
facade for Loggers, but it's a major break in our main code contracts.

How so? It looks mostly like just a different package name.

And that's nothing? ;-)

It's like saying that the "String" class moves package. It's disruptive. Hence we will probably do any such change in Avalon 5.

We are discussing about Avalon 5, and Configuration and Logging are a
major part of that discussion. You are invited  :-)

Cool.

...

So let me say the opposite: is Commons Logging advocating IOC?

No its agnostic. It doesn't advocate anything other than loose coupling to
any specific logging implementation.

Good.

What is the preferred method to get a Logger?

Whatever a component developer wishes. Either IOC or a static method. i.e.
push or pull depending on how a component is developed & used.

The problem here, that I would like to be solved eventually with your help, is that of the use of static-method-using packages in IOC containers.

That is, it's easy to do the opposite, use a static method to acces an IOCzed package, but the opposite is a problem. We cannot route the logging to an ioc method if we wish.

Looks like an AOP-like system to intercept all logs of a package could help, but I'm lost here.

Come on, be fair. It's the static accessor.

The static accessor is in no way mandatory - its just how folks coming from
a log4j background tend to do things. There's nothing stopping IOC being
taken up on any commons component - there's no need to grok the whole IOC
thing and move to Avalon Framework to start using this pattern.

Never said that and never intend even remotely to suggest it.
Avalon framework is ok for components that live in an Avalon container. Jakarta Commons packages do not fit this scenario.

Also note that these same static accessor methods are right there in JDK 1.4
logging, log4j and logkit too.

Too bad ;-P

In other words what I was trying to say in this thread was

* rejecting commons logging because it doesn't advocate IOC isn't a very
good argument - commons logging can be used in as much an IOC way as Avalon
Framework Logging and LogKit and indeed already is on some commons
components.

Ok, I'm cool with this. What makes me nervous is the real-life use of the commons logging configuration system and static accessor. It muddles things. If a package is not written to some rules that help in this, and please help me gain insight on this, then it's going to be a PITA.

* encouraging component authors to work with the IOC pattern of logging
(i.e. providing a setter method for Log) is a good thing, especially if that
component gets deployed in a container like Avalon etc.

Exactly the point. Yes, I agree.

No religious war. There is too much misunderstanding.

Logkit is not a facade, it's an implementation. We *are* talking about
synergies with log4j though. We'll see.
And as for the framework part, it's going to be part of the A5 discussion.

OK so I guess I'm talking about Avalon framework logging then.

Yes. Logkit is probably not going to be a future Avalon product, we'll see.

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.

We don't want a dependency on a package that has a static accessor to
get a logger.

Why? You don't have to use it? Do you rule out JDK1.4, log4j and logkit as
well then?

Then I'm wrong. This issue is related to the percieved common (mis)usage of the static accessor.

You may not need it, but why not put this possibility at all.

If a user has Commons Logging in the classpath, and there is a conf
problem, it's a PITA. In the server world, it really is.

Only if its used that way. Like I said, this doesn't have to be the case.
Plus a container can install its own LogFactory and do all kinds of groovy
things if it wishes.

Errr, it's still a PITA.

Look, I have some requirements that I'd like to be addressed somehow, let's see if you can help me.

1) a library should be able to work even without commons-logging
in the classpath

2) it should be possible to pass the logger to the library instead
of having it search for it via static accessors

3) if commons logging is in the classpath and the logger is not set,
then it can log only if an environmental variable based on
the library package is set

This means that if I want to log, I have to add an environmental variable for every library I want to log, and put commons logging in the classpath, or set the logger on each package I want to log.

What do you think? What of the above seems unreasonable to you?

Let's see if we can work this out :-)

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? :-)

We had our Logger with a worldful of utility methods for easy logging
without having to +++ strings together by hand all the time.

So are you talking about Avalon Framework logging here? Or logkit?

SF POI ;-)

I enable commons logging only if an environment property is enabled.
Simple. And no users complaining about it not working for a logging
package that is only for developers.

Again which facade/API?

POI has it's own log class, for historical reasons. It has bazillion of methods for utility. Quite dumb implamantation, but still helpful for a project like POI.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]