Re: [CLI] new design possibly?

[Nicola Ken Barozzi]

Henri Yandell wrote, On 07/02/2003 22.39:

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote:

Henri Yandell wrote, On 07/02/2003 17.32:

I don't see how this can work without ensuring that another package,
commons-stub is in the classpath. I know I'm definitely not going to copy
and paste pieces of code from library to library to handle looking for
commons-logging.

package org.apache.myproject;

public class Logger extends SafeCommonsLogger

I don't understand. Sorry. Where is SafeCommonsLogger? In commons-stub?

It's in my head ;-)

An abstract class to reuse to make a logger per package. This means really safe and fool-proof scoping.

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

Explosion of API. This is unnecessary overloading. Why isn't it simply
handled via a factory mechanism? Akin to JNDI.

Again... we don't want factory methods...

I'm not saying that you have to agree with me on IOC, just acknowledge
that it's a reasonable thing to do. Heck, just one method, is it too much?

I'm not big on the factory thing, just an idea etc as I'm doing a lot of
JNDI at the moment.

The problem for me is that your solution is one method in every single
library. That seems to send off alarm bells in my head.

Until I see your solution [is it somewhere?] I'm probably not
understanding it.

A stupid initial version is here (just to show you what I mean):
http://cvs.apache.org/viewcvs/jakarta-poi/src/java/org/apache/poi/util/POILogFactory.java?rev=HEAD&content-type=text/vnd.viewcvs-markup

Beware though that I'm using a special Logger because of our development needs:
http://cvs.apache.org/viewcvs/jakarta-poi/src/java/org/apache/poi/util/POILogger.java?rev=HEAD&content-type=text/vnd.viewcvs-markup

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?

All of the above :) Plus adding an envrionment variable per library is a
poor management technique. I want to store them all in a file, not as a
host of -D arguments or even in code.

Ok, the problem arises when a user has multiple of these files in the
classpath. I've seen it happen more than once.

Agreed. I have this problem with log4j.properties constantly when a jar
I've deployed is hiding its own little log4j.properties file.

Exactly. This is what I really want to avoid.

Poor management technique? I'm just talking about utility libraries.
As a user, do I ever have to manage logging, or even remotely have to
deal with it?

The example Java user for me is my company's Java Admin. So yes, he does a
fair bit of work on managing the logging :)

hehehe

I want to get XJar and use it. No logging, I'm not a developer. This is
the use-case. Any other possible solution?

Unsure if I really understand the issue here. Are you against CLI having
any dependency? If I add a feature which makes it dependent on
Commons-Lang tomorrow, is this going to upset people?

Well, I would prefer it not to have any dependency. But it's a secondary issue. It's specifically the hard dependency on commons logging that I would like to not have.

When I grab XJar, I grab the dependencies [there ought to be an installer
that does it for me though].

I'm happy to agree that commons-logging should be quiet by default and not
print anything out unless there is some kind of configuration way
[logging.properties or whatever] to turn it on.

Exactly. I showed you how poor logging.properties is. I proposed a more safe but less elegant -D solution. What else can be done?

I'm nothing to do with commons-logging btw, am a user/potential-user like
yourself.

I know :-)

Let's continue on the new thread, shall we? :-)

--
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]