forwarded at Peter's request
-------- Original Message --------
Subject: Re: Common Logging Interface
Date: Tue, 20 Nov 2001 11:38:29 -0500
From: "Richard Sitze" <[EMAIL PROTECTED]>
To: Berin Loritsch <[EMAIL PROTECTED]>
CC: [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.
<ras>
Perhaps I'm still missing something.
I think you are saying that there is the logging framework (Java package),
AND there is the Logging aspect of the Avalon API,
AND there are other aspects of the Avalon API.
Is this correct?
</ras>
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.
<ras>
We like to think we defined scalable solutions :-)
Seriously, it's not a matter of skills, its a matter of
planning, direction, and various other factors.
</ras>
> 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... :)
<ras>
And I'll be happy to evangelize as I learn more, and if I can see benefits
beyond what we currently have. Not to say they are not there, just that
I've got a lot to learn. And I appreciate you patience with me.
</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?
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>
I don't see how use of logger categories applies to obtaining a logger
reference from JNDI. JNDI will give me existing objects, not go to a
factory if it cannot find it...
I think I'm missing something again.
</ras>
> <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
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
.
--
"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]>
