logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Randall" <javabr...@gmail.com>
Subject Re: Future of JULI<->Log4j bridging
Date Mon, 08 Sep 2008 05:30:05 GMT
Hi Paul,

On further reflection on how to bootstrap the bridge ...

With JUL it is possible to use a system property to control the
LogManager class.  So I created a class:

    /* *** */
    package org.apache.logging.julbridge;

    import java.io.IOException;

    import org.apache.log4j.LogManager;

    public class JULBridgeLogManager extends java.util.logging.LogManager {

        public void readConfiguration() throws IOException, SecurityException {
            JULLog4jBridge.assimilate(LogManager.getLoggerRepository());
        }
    }

Then, I can set
-Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager
for my JVM startup, and the bridge is activated on the first call to
the LogManager, when a Logger is first requested.  There seems to be
sufficient synchronization protection around this.

This works for me and avoids a) the initial JUL LogManager
initialization (minor) and b) the need for a static call to activate
the bridge, nicely replaced with a system property.

Does this look sane to you, or has this approach been ruled out previously?

Cheers
Brett

On Wed, Sep 3, 2008 at 2:57 PM, Paul Smith <psmith@aconex.com> wrote:
>
> wow!  cool!  this is great news to hear.  Now we have 2 users! :)
>
> If you're interested in trialing things one day, look out for Pinpoint (currently an
Apache Lab).  It's for log data mining.  centralised log repository with full text indexing
and reporting.  I'm right in the middle of a load test for it as we speak (soaking events
from 2 hosts, at 100 events/second, this is a Mercury load test of our actual application
running realistic production loads).   Unfortunately there's no real UI for actually doing
the searching as yet, but the indexing side is working very well.
>
> cheers,
>
> Paul
>
> On 03/09/2008, at 2:20 PM, Brett Randall wrote:
>
>> Thanks - all good and working for now.  Bridge version
>> apache-jul-log4j-bridge-1.0.0-20071030.02281 appears to work well.
>>
>> Using Spring Framework, I can actually bootstrap the bridge during the
>> Spring context load using this:
>>
>>   <bean id="jul-log4j-bridge"
>> class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
>>       <property name="staticMethod">
>>
>> <value>org.apache.logging.julbridge.JULLog4jBridge.assimilate</value>
>>       </property>
>>   </bean>
>>
>> ... which I think is nice.  No reference or dependency on the
>> jul-log4j-bridge in my code, deploy-time replacement of JUL backend with
>> log4j.  Then I can even plug-in Chainsaw:
>>
>> (log4j.xml)
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd" >
>> <log4j:configuration>
>>
>>   <appender name="console" class="org.apache.log4j.ConsoleAppender">
>>       <param name="Target" value="System.out" />
>>       <layout class="org.apache.log4j.PatternLayout">
>>           <param name="ConversionPattern" value="%d [%t] %-5p %c - %m%n"
>> />
>>       </layout>
>>   </appender>
>>
>>   <appender name="chainsaw" class="org.apache.log4j.net.SocketAppender">
>>       <param name="remoteHost" value="localhost" />
>>       <param name="port" value="4445" />
>>       <param name="locationInfo" value="true" />
>>   </appender>
>>
>>   <root>
>>       <priority value="debug" />
>>       <appender-ref ref="console" />
>>       <appender-ref ref="chainsaw" />
>>   </root>
>>
>> </log4j:configuration>
>>
>> Very happy - thank you for contributing this code.
>>
>> Cheers
>> Brett
>
> 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: psmith@aconex.com  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.
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message