<snip> >> Even if I accept that adapter plugins, I must now deal with configuration >> for each middleware component. It begins to grow (Log4J, LogKit, JLog)... >> When I want to enable tracing I've now got to go through I-don't-know how >> many configuration points to do so, and communicate to my end-users >> multiple different mechanisms to enable/disable tracing at different points >> in the code. Guess what: my own selfish desires aside, my users don't LIKE >> more than one way to configure tracing... I'm thinking that I have a >> better chance of getting a common pluggable interface from you folks that a >> common configuration scheme!!! > >The LogKitManager (that can easily be adaptable) is your savior. This will >allow one file to describe the entire log heirarchy and Logger names for them >all. The LogKitManager (which would in this case change it's name to >LoggerManager) would even be able to set up loggers from multiple sources in >one system. > >If you wanted a Logger that talked directly to a Third-Party Logging implementation, >you would create a wrapper/adapter for the implementation, and a Factory so you >can choose it for the LoggerManager. >
Terrific. Now if only I could replace Log4J with LogKit in my middleware... some programmer started his project off with Log4J and the API's just aren't compatible. And I don't want a Log4J adapter that wraps the LogKit API, because then I cannot use the LogKitManager - it doesn't have the visibility and context that Log4J has... <snip> > >Keep in mind that with modern compilers (like JDK 1.3+) make some optimizations. >The wrapper classes are declared final, as well as all the methods and internal >variables. In essence, in the run-time, the wrapper is optimized out, and the >contents of the code are in-lined. > >This achieves very little to no overhead. Excellent point... something to think about - thanks. > >> I'm not proposing that we solve all the problems, just try to take >> advantage of the simularities where they are to help encourage people to >> use the framework... Perhaps what I'm advocating is equivalent to >> >> 1. Moving the avalon framework to an apache common tool... > >The whole framework? Or just the logging part? We need to resolve this >soon, because it affects my release plans for Framework. No, I'm only talking about the logger, and only if we can align with Log4J. > >> 2. Make the minor mods to LogKit and Log4J >> (the two predominant open-source logging API's) >> to eliminate overhead of wrappers entirely when >> used with the framework... > >Here is the deal with that approach: > >Requiring a supposedly self-contained jar to implement interfaces from an >external project now REQUIRES all users of the jar to now incorporate that >other jar. Either that, or include the other jar inside the self-contained >jar. That would mean that both LogKit and Log4J would be required to include >the contents of the shared interface jar. Can you imagine the classloader >issues? Why? The framework guarentees that only one of them gets loaded into the JVM.. the other isn't needed. <ras> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
