Ok, now we're getting somewhere. Thanks Costin.
>This is going to be used by (probably) many commons and outside packages,
>and ( as mentioned many times) it will be _required_.
Just to clarify this statement, which otherwise may lead to some confusion
when reading my responses below:
A. If you are going to be using a component that uses this logging
abstraction, you will be required to have at least Log, LogSource and
whatever your logging glue of choice is (e.g., NoOpLog if you don't care for
logging, Log4JCategoryLog if you want log4j support). Nothing more, nothing
less. No application that wants to use a "logged" component needs use the
logging abstraction, whether or not they are using logging within their own
code.
B. I would not expect this logging abstraction to be used by outside
packages. The goal and scope of the proposed package is to provide a simple
and implementation-agnostic abstraction of logging--one that is adequate for
the relatively simple logging needs of a component, and one that is painless
to integrate with the "containing application"'s logging implemenation of
choice (even if that implemenation of choice is to not use logging).
>1. (major) As far as I can see, Logging has exactly the same security
>problems as log4j ( in logging.LogSource class ). Even worse, at least by
>using log4j ( as Ceki mentioned ) you can get secure logging by using
>separate hierarchies, while the proposing logging is just hopeless.
What precisely are your security concerns here? That I may be able to
intercept logged messages or possibly hijack a Log (Category) altogether? I
guess I imagined little or no security concerns with the kinds of log
messages a commons component would need to send, and with a little restraint
(e.g., DBCP shouldn't be sending database passwords around) I think that's
pretty much true. Can you clarify your concerns here?
(As an aside, what kind of an environment are you working in in which you
can't trust/control the code executing in the same VM? Even applets are
sandboxed from one another, right?)
>2. (major)Using system properties to create the logger... What if you're in
>a sandbox ? How many system properties do we need ? ( IMHO system
>properties are over abused, they are nice but using them as the only
>mechanism is not that good ).
What are you refering to? No system properties are required to
create/configure the logger in the general case. If you have log4j in your
classpath, log4j categories will be used, configured however you normally
would. If you don't have log4j in your classpath, the NoOpLog is used.
It's only if you want to use a different logging implemenation that you'll
need to add a *single* property indicating the name of the Log
implementation you'd like to use, and if we wanted to make the defaults a
little more clever, e.g., if log4j, then if logkit, then if merlin or
whatever, we could do that.
One can simply extend/enhance/replace the LogSource class to change this
behaviour. If you've got a patch in mind, feel free. I don't see how this
should be a major issue.
(Pay no attention to the SimpleLog implemenation of Log. It support
configuration via properties, but that's just an example as much as
anything. It is there to support those who feel System.out.println is
sufficient for their logging needs.)
>3. (major)Obviously, performance. I believe recycling is essential for
>scalability and performance. LogEvent can be used for that ( with some
>enhancements ), the current Logging is again hopeless.
What objects would you like to see recycled in the current logging
abstraction? As far as I remember, every object that is created by the
logging abstraction is created exactly once.
I'm not sure I see a measurable performance hit in the logging abstraction
either. There's one extra method call per log statement (versus direct
log4j logging, for example), but that seems pretty minor. I'd bet every one
of the commons components has bigger areas for improvement than that. If
that level of performance hit is significant, then you're really calling for
no logging at all, or conditional compilation for creating log free builds.
>4. (minor) I also don't like the use of Iterator in the interface ( no
>problem with using collections in the implementation, but I see no reason
>for it in the interface - Enumeration would work as well ).
And vice versa. I don't see any particular advantage to using Enumeration
here, but the disadvantages I see of using Enumeration are minor as well.
Six of one, half-dozen the other.
>5. (major)Static all over the place in LogSource. That's the source of all
>the problems in Log4j.
Bear in mind that the logging abstraction and log4j have different goals in
mind. If it made everyone feel better, we could certainly make LogSource an
interface and provide a singleton and a factory or something, but that also
adds bulk and complexity to the abstraction. What specific change did you
have in mind?
>6. (minor)newInstance - creating the class with empty constructor and then
>setting params is the common pattern almost everywhere.
If I know every one of these things is going to need a single string
parameter (and I do know that, by the LogSource contract), then why bother
with a no-op constructor? Doesn't matter much to me either way though.
>7. (minor)setLevel, as Peter pointed out.
Some users wanted a mechanism for turning the log on and off via method
calls. Seems harmless enough. If you don't like it, don't use it. I don't
particularly like it, and I imagine I won't use it. Think of this as an
"external" method, only to be used by clients to the commons-component.
Again, thanks for bringing some specific concerns to the table.
- Rod
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
