Receiver Proposal

[mw...@apache.org]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Receiver Proposal

[Oliver Burn <ol...@puppycrawl.com>]

It sounds like a good proposal. The only question I have is that I get a lot
of requests for Chainsaw to include the originating host for each logged
message. Using the current approach by Chainsaw I can modify the receiver to
include this information. This scenario would not be handled by the proposal.
Personally this is not a problem, but something to be aware of.

Oliver

> -----Original Message-----
> From: mwomack@apache.org [mailto:mwomack@apache.org]
> Sent: Friday, 28 June 2002 14:41
> 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Receiver Proposal

[mw...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>