I have got the JULAppender (subtle rename, made it upper case to
match the rest of the bridge projects naming conventions) into the
bridge project in my local workspace.
I've slightly changed the Appender to use the JULLevelConverter
interface so that users can customize the Level mapping. I've added
a test case to cover this. Files have been moved into the .jul
package name spaces as well.
What's odd is that running all the unit tests inside Eclipse pass
fine, but not under maven. I haven't worked out what is going on
there, it appears the TestHandler (renamed AssertionHandler to
prevent maven thinking it's a unit test) is being activated by a
trace level event when it shouldn't. I don't quite understand it yet.
Sagi, if I commit my local changes soon, would you be able to
checkout the bridge project and help debug this?
cheers,
Paul
On 25/06/2007, at 4:42 PM, Sagi Mann wrote:
Thanks for the feedback, makes total sense to me as well.
Sagi Mann
-----Original Message-----
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 09:44 AM
To: Log4J Developers List
Subject: Re: JUL appender
On 25/06/2007, at 4:32 PM, Sagi Mann wrote:
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)?
In terms of code change, it is only an additional JAR file that would
need to be added into a deployed project. If the JULAppender was
added to log4j 1.2.15, the user would still need to update their
log4j jar, so it's not really any different.
I think Curt's concerns of changing log4j 1.2.15 this late is
warranted, and I don't see this Appender as a core component. I
would have thought putting it in the bridge project was a logical
place. "Anything java.util.logging that relates to log4j is in here".
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]
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED] www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
