----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 8:17 PM
Subject: Re: JDK1.4 logging vs. LogKit
> On Thu, 9 Aug 2001 10:15, Mircea Toma wrote:
> > ----- Original Message -----
> > From: "David BERNARD" <[EMAIL PROTECTED]>
> > To: "Avalon Development" <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 08, 2001 6:40 PM
> > Subject: Re: JDK1.4 logging vs. LogKit
> >
> > > Hi Everyone,
> > >
> > > I'm newby in Avalon and C�, and I've got a suggestion (if stupid say
> > > it).
> > >
> > > Actually I do a evaluation for "services engine"for my client, and
I've
> > > promote Avalon.
> > > The first set of services is for the migration of a old big java
> > > application. This application have some target in services management,
> > > log...
> > >
> > > In the first step, we design a from scratch system, and the choice for
> > > log is : "log is a service like anyother".
> >
> > No quite.... the logging is a fundamental part that should be available
> > immediately, it means that a Hierarchy has to be instantiated in the
> > container.
>
> I tend to agree. I put it in the same boat as ClassLoader and thread
> managment.
>
> > >So why, it's not a nice/good
> > > idea to define a role Logger and use a LoggerSelector (use category
> > > string as key) to get the instance of Logger.
> > > In this case, there implementation for LogKit, Log4J... and the
> > > configuration of Log system is independent of each Component
> > > configuration (The default category a component can use is the ROLE
> > > constant).
>
> Thats the way Avalon/Phoenix used to work about a year ago. We had a
Logger
> service that allowed all sorts of pluggability. The problem was that every
> block would require access to this service. This created a lot of
redundent
> coding in each Block. The other problem was you could not log any problems
> earlier in lifecycle - ie WHat happens when you want to log data in
> contextualize() method.
>
> > I already did that in the project I work and I can tell you it's not the
> > best approach. I think you can have only LogTarget-s as components
> > configured to use a certain Hierarchy ( we have two Hierarchies for
logging
> > and auditing). In this way you can have a configured LogTargetComponent
> > like: FileTargetComponent, DatabaseTargetComponent,
JMSQueueTargetComponent
> > ..... and you would configure them to with a certain Hierarchy, Category
> > and Priority as common attributes.
>
> Thats kinda the way I have been swaying recently but I really don't want
to
> create a circular dependency (ie framework depends upon logkit and logkits
> output targets depend on framework).
I agree! The components should be part of Excalibur/Phoenix or just custom
components!
Cheers,
Mircea
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
