I have a few questions: I originally concentrated on ease-of-use as much as possible. I, as Arnold, am concerned that usage will become overly complex. Current use is to treat JulAppender as if it was ConsoleAppender (even replacing any refs to ConsoleAppender with JulAppender would work). This way, existing log4j apps running in JUL environments will have better integration without any changes to code or deployment (log4j config can be changed without the need to redeploy everything).
Will usage be somehow affected if this appender is provided outside log4j itself? (i.e. apps may need to be redeployed, jars added, etc) Will usage be somehow affected if this appender is provided as a part of a larger "jul bridge" package (i.e. more complex configuration, env prerequisites, code changes, etc)? thanks, Sagi Mann -----Original Message----- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 06:08 AM To: Log4J Developers List Subject: Re: JUL appender
Answers that I'd be looking for:
Are the log4j->jul and jul->log4j solutions symmetric: For
example, if there is a JULAppender, is there a corresponding
Log4jHandler?
The original bridge code dealt with jul->log4j only. The new JULAppender code provide by Sagi Mann is the symmetric equivalent. Since the jul-log4j-bridge project requires JDK 1.4 to build, I think it makes sense to add it to this project rather than log4j itself. There is also some code sharing the Receiver and Appender can share in terms of the LevelConverter interfaces.
Are the names appropriate?
Is the packaging appropriate?
Happy to discuss packaging options. I personally like: * org.apache.log4j.jul - for code dealing with log4j<->jul or for log4j specific code. The JULReceiver is the classic example here, that's the package it sits in in the bridge project * org.apache.logging.julbridge - Generic/bridge specific code, mostly dealing with the jul packages (such as the Filter and Handler implementations. There are no log4j related imports in this section, so it's quite isolated. That's what is sitting there now. I'd propose to add the JULAppender class to org.apache.log4j.jul in the bridge project and update the site documentation for the bridge project on how to use it
What are the performance issues?
I think the only real way to test this is a stress test, but by code inspection it's pretty light.
Is anything overly complex?
I think you'll find it's actually all quite trivial. Be great if you (and anyone else) could review it. cheers, Paul --------------------------------------------------------------------- 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]
