Forwarded at Peter's request
-------- Original Message --------
Subject: Re: Common Logging Interface
Date: Tue, 20 Nov 2001 11:15:55 -0500
From: Berin Loritsch <[EMAIL PROTECTED]>
To: Richard Sitze <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Richard Sitze wrote:
> 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>
Then why use it ;P
>>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>
Here is my point. The abstract logging API is part of Avalon framework.
If you include the Avalon Framework Jar into WebSphere, you don't have to
suddenly migrate all at once. You can take the Logging aspect (Separation
of Concerns remember?), and use only that aspect. When you want to adopt
the other lifecycle aspects of Avalon Framework, then you will gradually
realize the scalability of its design.
In the end, if you use the abstraction API, it does not require you to use
the LogEnabled interface to obtain the Logger. However, if you do, it is
not only prefered, but you have taken the first step toward anabling your
application towards Avalon's features. I don't doubt that IBM can hire
capable programmers that can write scalable software.
> 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>
It sounds like you are hung up on IoC, when all you really want is the Logger
interface. In the end, the Logger interface is all you need for your purposes.
If you don't like Avalon's preferred method of providing the Logger instance
to the Components, then you are free to invent your own.
I must reiterate that requiring us to change our API to violate our design
principles is not an option. In that respect, you are right, it is our
way or the highway. If you would like to augment our loggers and provide an
alternate way of obtaining them, then knock yourself out.
> 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>
Then adopt the logging part of the framework--you will have some extra interfaces
and classes lying around, that you will inevitably want to use later.
(I'm being optimistic).
>>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.
I still don't see where there are required 2 frameworks.
>>(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>
A little evangelism goes a long way... :)
>>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?
I can tell you now exactly how Peter envisioned it's use (because I know
him):
We are talking about two contracts, both follow IoC. Let me expound on this.
The first contract is the one explicitly in Framework (setLogger(Logger)).
This one we both understand. The second contract is with the LoggerFactory.
The LoggerFactory is set up _BY_A_PARENT_CLASS/COMPONENT_. It is then used
by the parent to get references to the Logger that a particular child needs.
This SAME instance can be used by child instances that have children.
Therefore, your root instance which is the container of containers sets up
the InitialLoggerFactory for all of it's children. It passes the
InitialLoggerFactory to it's child containers, which in turn use it to set
the logger for their children.
It is still IoC, and it allows category hierarchies that do not match the
component heirarchies.
With the example he described, it looks very similar to (if not ripped directly
from) the JNDI approach. You are able also to use JNDI to get your precious
Logger instances. This reduces the amount of code you need to create, let's
the JNDI system set up and configure the loggers, and your components/javabeans/
whatever can get the Logger instance from JNDI. That approach seems more like
what WebSphere is looking to do with their system anyway.
> <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
--
"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]>
