Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
From: <mwomack@apache.org>
To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
Subject: RE: Receiver Proposal
Date: Sat, 29 Jun 2002 11:16:52 -0700
Message-ID: <NEBBLPOOIKCGBKMCPNCGIEGACLAA.mwomack@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <NEBBLPOOIKCGBKMCPNCGMEFECLAA.mwomack@apache.org>

What does this buy us? continued...

4) If designed with a proper extendable design, the Receiver class could be
used to bring other types of logging messages into the log4j environment.  I
know that support for other logging packages is a non-goal in general, but
the Reciever class would make it easy for developers to handle these cases
if they need to.  It should be relatively simple to create a
JDKLoggingReciever that would get messages for the jdk logging package and
then "translate" them into the log4j environment.  Other logging packages or
other sources could be handled in a similar way.

-Mark

> -----Original Message-----
> From: mwomack@apache.org [mailto:mwomack@apache.org]
> Sent: Thursday, June 27, 2002 9:41 PM
> To: Log4J Developers List
> Subject: Receiver Proposal
>
>
> Sparked by my recent modification of Chainsaw and my wanderings
> through the
> LF5 code, I am going to make the following proposal.  Please
> comment as you
> see fit.
>
> The proposal:
>
> Just as log4j has support for Appender classes, of which custom
> versions any
> developer can create, how about a Receiver class?  Receiver
> classes would be
> instantiated and attached to logging repositories, just as
> Appenders.  They
> would be named and configurable via a configuration file, just as
> Appenders.
> As its name indicates, a Receiver would receive events (most likely from a
> remote source), but instead of appending them as an appender
> does, it would
> post the events to the repository as if the event had been generated
> locally.  This behavior would be like the current
> SocketServer/SocketNode/JMSSink.
>
> What does this buy us?
>
> 1) When I write an appender, I could write a matching receiver.  This
> receiver would be automatically usuable within the log4j
> framework.  No more
> SocketServer/SocketNode/JMSSink classes that need to get executed
> outside of
> log4j and that users can't figure out how to configure and run
> without extra
> effort.  Instead, we would create SocketReceiver, SocketHubReceiver, and
> JMSReceiver.  You could run some really basic main application
> that loads a
> configuration file with any of these receivers configured and you
> are done.
> The configuration would be no harder than any other type of configuration
>
> 2) Riding on #1, it will be easy to write your own custom remote event
> logging server.  Just configure some basic code to use a
> configuration file
> with receivers defined.  Since receivers will be associated with a
> repository, you can attach different appenders to the same repository and
> have it do whatever you want with the received events.  You could even get
> fancy and create a useful Swing gui to configure things via an window.
>
> 3) Log event viewers/clients, like Chainsaw and LF5, would be
> able to start
> receiving events from new types of appenders/receivers automatically, no
> modifications required.  Just hook the matching receiver into the
> configuration and you are done. (This assumes that a
> ChainsawAppender would
> be created, similar to the LF5Appender)  This becomes the standard way to
> hook any new viewer/client into log4j.
>
> Why can't you just write a special Appender that does what you want?
>
> Appenders are really designed to send logging events outside of the log4j
> environment (file, smtp, telnet, jdbc, you name it).  You could write an
> appender that received events and posted them to the local log4j
> environment.  But then it would need to have empty append()/doAppend()
> methods that do nothing since you wouldn't want them to deal with the same
> event twice.  It would be a very obvious hack.  Better to make
> the Receiver
> concept a first class logj citizen and class.  Just as appenders
> send events
> outside the log4j environment, receivers would bring events
> inside the log4j
> environment.
>
> That's it for now.  Comments?
>
> -Mark
>
>
> --
> To unsubscribe, e-mail:
> <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:log4j-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>