----- 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]
