forwarded at Peter's request
-------- Original Message --------
Subject: Re: Common Logging Interface
Date: Tue, 20 Nov 2001 10:30:00 -0500
From: "Richard Sitze" <[EMAIL PROTECTED]>
To: Berin Loritsch <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Sometimes I hate Lotus Notes - I really want the ">" inserted before each
original line automatically, but Notes won't do it...
My comments <ras>below</ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Berin Loritsch
<[EMAIL PROTECTED] To: Richard
Sitze/Charlotte/[EMAIL PROTECTED]
che.org> cc: [EMAIL PROTECTED]
Subject: Re: Common Logging
Interface
11/19/2001
04:49 PM
Richard Sitze wrote:
> All right, I think I'm in sync again. Comments below.
>
> Berin Loritsch wrote:
>
>
>>Richard Sitze wrote:
>>
>>Keep in mind that Avalon is built with IoC and SoC (Inversion of Control
>>and Separation of Concerns). The document explains alot.
>>
>
> Doesn't apply. My goal/focus is your logging framework, not the entire
> Avalon framework. As wonderfull as Avalon looks, it is simply not an
> option today. I want an open-source **logging** framework that is not
tied
> to Log4J, LogKit, or any other technology. Your logging framework is a
> solid basis (if I can resolve a few issues). I grant that a logging
> framework is very simple and small, but we really don't want a nth API.
It does apply. If you want to extend the Avalon Framework with your
logging framework that adds some extra pieces, that would fine by me.
I just haven't heard any solid arguments to make me want to break backwards
compatibility or violate the design principles we so strongly adhere to.
<ras>
One of us is missing something here :-) Seriously, it doesn't apply today:
I'm not extending Avalon Framework. I'm not using the Avalon API. I'm
trying to adopt a logging framework into a legacy server: say "IBM
WebSphere Application Server" 10 times... While I wouldn't rule out
adopting WebSphere to Avalon in the future (anything can happen), it's not
on the table now. Meanwhile, we bring OpenSource technologies (Tomcat,
AXIS, Eclipse, and other's I'm sure) in, and put them to work because it's
what our customers want.
</ras>
> Note that, outside Avalon, there are commercial servers that want to
> leverage open source technology. That's to everybodies benefit. So,
help
> me come up with an open-source logging framework that works for Avalon
and
> other servers as well.
Then let them take advantage of Avalon's API. Eventually, they may have
to anyway. JSR-111 (Java Services Framework) is aimed at J2EE servers and
other servers to plug in new services--middleware and otherwise. All the
frameworks mentioned in the JCP overview (including Avalon) are built with
the same design principles.
You may think I am being flippant, but I'm not. Every project that has
decided to use Avalon Framework/Excalibur has only responded with positive
feedback. Most of them rave about how easy it is to keep the system free
from lifecycle mismanagement bugs and other systemic bugs. I haven't heard
anything beyond the learning curve issue--which is now made much smaller
with decent documentation. Abandoning our design principles and patterns
would be a detriment to everyone involved.
<ras>
Not an option. I'm not being flippant either, but I feel as though I'm
being told that "it's my way or the highway". I hope I'm not comming
across that way, I just want something that works for our requirements
(just like you), and that's what I'll get in the end. I'd prefer that it
be based on something already out there, if we can resolve the issues. If
not, then I'll end up with an n-th API.
</ras>
>>>BTW, AbstractLogEnabled doesn't seem very useful. Example: myServlet
>>>extends HttpServlet, and since Java supports only single-inheritance
>>>myServlet is now unable to extend the AbstractLogEnabled class.
>>>
>>In this case, the HttpServlet is the ROOT class, therefore it creates
>>the initial logger and reads the configuration used to set up the
>>environment.
>>This is the way Cocoon works.
>>
>
> I think this means that I have to use your implementation of HttpServer.
> See above, it's not an option for everyone.
No. This means that whatever sets up the environment sets up the initial
Logger implementation. That was a use-case.
> Agreed, but it's a philosophy built into your server. My philosophy is
> trying to integrate other open-source middleware solutions into our
server.
> My approach (at the moment) with regards to logging is to replace
whatever
> logging API is being used with a logging framework... let the server
> (Avalon or mine), not the middleware, determine the logging API. If I
can
> work out the details I will be in a better position to approach and
propose
> such a framework to the specific development groups (AXIS will be first).
It's a philosophy built into the API. If you want to extend our API, and
defeat all the protection we have in place, knock yourself out. It won't
be Avalon, and it will most likely create issues later down the road.
Asking
the Avalon team to abandon their design principles "for just this piece"
is rediculous. It's not going to happen.
<ras>
Right, It won't be Avalon. But I'd still like to use the logging
framework.
</ras>
> One of the biggest hurdles will be the LogKit/Log4J differences at the
> method-call level (interface, ultimately). There are two of these:
> 1. fatalError versus fatal, and
This is a very minor issue. We chose the name we did because we have an
installed base of LogKit users. Those who are already using LogKit in
Avalon should have the easiest migration path possible afforded to them.
> 2. forcing IoC where it isn't used today (think legacy code, even if
> open-source).
>
> Your choice on the first seems to be a bit arbitrary. I don't want to
> pound you on this, but that made things more difficult.
Sure you want to pound me on this, that's why you keep bringing it up ;P.
<ras>
Caught me red-handed!
</ras>
> I'm hoping we can resolve the 2nd easily enough... If not, that means
two
> logging frameworks: very similar, but one based on LogKit/IoC, and the
> other based on Log4J. The advantage to one framework is it might help
> force Ceki's hand.
Look, I don't want to force anyone's hand. The Avalon Framework was kind
enough to allow an abstraction layer so that you can use Log4J or LogKit
with new development. If you use Avalon, you have bought the concept of
IoC and SoC. You can defeat the whole IoC by creating a static class with
access to the root logger--I would advise against this, but it is possible.
>>Keep in mind that there is no such thing as absolute security. All you
>>
> can
>
>>do is raise the barrier to unauthorized access until it becomes not worth
>>the trouble. By using a common practice throughout the entire framework,
>>the framework becomes more modular and maneagable while simultaneously
>>raising the barrier to unauthorized accesses.
>>
>
> OK. That was the point I wanted to make. Would you agree that your
> framework should be sufficient to resolve your concerns with Log4J? That
> appears to remove one of the most fundamental differences between you
> (Berin & Peter) and Ceki. You don't NEED log4J to buy into the IoC
> philosophy, but neither can you give up LogKit entirely. Continuing to
> make LogKit available is essential, given that if you remove it you
> encourage malcontents to target Log4J...
:)
Seriously, the Avalon Framework with Log4J or with LogKit will be secure.
Are we going to give more attention to LogKit? yes. Are we going to
rule out Log4J? no.
> Which brings me back to my original points, can we strive to get your
> Logging Framework in closer sync with Log4J.
The points of contention (other than IoC) are purely cosmetic. You can't
satisfy an installed user base of Log4J AND LogKit. It is impossible.
Because Avalon LogKit is our baby, we are naturally going to opt toward
that API. It's that simple.
In reality, the number of fatalError() log messages are very low--if not
then you have a seriously flawed system. Most projects can handle the
one or two locations where they have to change fatal() to fatalError().
> On the other hand, I still need to have more control over the category
name
> (I'm NOT using IoC, nor am I in a position to introduce into my
> internal/legacy logging API's, middleware, etc).
Are you NEVER going to use IoC? An API isn't very useful if it doesn't
discoruage bad design.
<ras>
Not until the WebSphere application server adopts it... and I'm not
writting the application, just working in my small corner of the room.
</ras>
> Here again, I would note that the factory proposed by Peter appears to
> allow me to specify the category name. What is to keep me from calling
the
> factory with a different category name whenever I needed? Doesn't that
> break IoC?
Which factory?
<ras>
Peter wrote, in an earlier note:
*************
Heres something I wrote in earlier mail.
----------------
My proposal for an abstraction layer was originally the below LogFactory
and
the Logger interface in Avalon repository. The LoggerFactory would behave
like JNDi in that it could accept a map that has parameters. The default
values of map would be populated by a config file in the Classpath.
interface InitialLoggerFactory
{
Logger getLogger( Map map ) throws NoSuchLoggerException;
}
example usage.
Hashmap map = new HashMap();
map.put( LoggerFactory.NAME, "some-category-name" );
map.put( LoggerFactory.CONFIG_URL, "file:/some/config/file.txt" );
map.put( LoggerFactory.FACTORY_IMPL, "com.biz.LogKitLoggerFactory" );
InitialLoggerFactory factory = new InitialLoggerFactory();
Logger initialLogger = factory.getLogger( map );
another usage that just used defaults sucked in from entries in ClassLoader
would be
InitialLoggerFactory factory = new InitialLoggerFactory();
Logger initialLogger = factory.getLogger( new HashMap() );
--
Cheers,
Pete
*************
</ras>
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
