Bug 48907 - Implement zeroconf support for additional receivers
Summary: Implement zeroconf support for additional receivers
Status: RESOLVED FIXED
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: log4j-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-14 08:33 UTC by Scott Deboy
Modified: 2010-03-28 04:26 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Deboy 2010-03-14 08:33:51 UTC
Include ZeroConf support for additional receivers (UDPReceiver, MulticastReceiver, XMLSocketReceiver).

Currently, _log4j._tcp.local. is the service name associated with a ZeroConfSocketHubAppender (a SocketHubReceiver initiates a TCP connection to the appender using port and host address information).  This should probably be left as-is to support existing deployments.

Two possible implementation choices: 
1. use _log4j._tcp.local, _log4j._udp.local. and _log4j._multicast.local. service names and require specific properties which will be used to construct the appropriate receiver

Example: a _log4j.udp.local. service name with an optional "decoder" property could be advertised or received to automatically construct a UDPReceiver
 
2. define new service names which provide all needed information

Examples: a UDPReceiver could advertise that it can receive events by defining a service name of _log4j_xml_accept_receive._udp.local., or a UDPReceiver could automatically be created if an external system advertised _log4j_xml_connect_send._udp.local.

One reason for using names would be if the external system's zeroconf implementation couldn't provide properties.
Comment 1 Scott Deboy 2010-03-15 07:09:37 UTC
What is needed to implement this feature?
 - Define supported service names (and optionally supported name/value keys)
 - Implement ZeroConf support for all appropriate receivers and appenders
 - Implement auto-creation of a receiver configuration in Chainsaw based on a discovered service

Proof of concept implementation
I've implemented a proof of concept which adds support for ZeroConf to the MulticastAppender & receiver, SocketAppender & receiver, SocketHubAppender & receiver (sockethubappender already has support via a subclass, but that won't be needed going forward), UDPAppender and receiver, and XMLSocketReceiver.

Each of these appenders and receivers now contains a new member: advertiseViaMulticastDNS

When activateOptions is called, if the value of this property is 'true', a new class in the core log4j tree (ZeroConfSupport) is instantiated and the appender or receiver 'service' is registered via JmDNS.  The service is unregistered when the appender or receiver is closed/shut down.

Service names need to be defined and documented in order to support advertisement of appenders as well as auto-configuration of receivers in Chainsaw based on these service names.  

This will allow other logging frameworks to register appender configurations and have Chainsaw automatically construct an appropriate receiver configuration.  

It will also allow those applications to discover receivers (possibly defined in Chainsaw) which they can send their events to.

Thoughts?
Comment 2 Scott Deboy 2010-03-15 07:13:07 UTC
One additional comment: this new ZeroConfSupport class in the core log4j tree uses reflection to register & unregister appender & receiver configurations in JmDNS, so no compile or runtime dependency changes are needed if the advertiseViaMulticastDNS member is set to 'false'.  

If the member is set to true but JmDNS is not in the classpath at runtime, the exceptions are caught & logged, and the appender or receiver will continue to run.
Comment 3 Scott Deboy 2010-03-16 04:10:35 UTC
After thinking about this a bit, here's a proposal for a service name convention supporting most of the network-based appenders and receivers we provide.

Other logging frameworks can conform to this convention in order to have log4j discover their services, and they can use this convention to discover log4j-advertised services).  

If, in the future, we want to advertise other appenders (like FileAppenders or FileReceivers), we will need to expand on this convention.

Support for existing ZeroConfSocketHubAppender deployments:
log4j._tcp.local.

Proposed service name convention:
log4j_[xml/obj]_[mcast/udp/tcpaccept/tcpconnect]_[appender/receiver].local.

We could also support service-defined encoders for xml-based appenders via an 'encoder' key, with the value being the fully qualified decoder class name.

xml: events are sent as xml fragments
obj: events are sent as serialized java objects

mcast: multicast UDP
udp: unicast UDP
tcpaccept: tcp serversocket (accepting incoming connections)
tcpconnect: tcp socket (connect to a remote server socket)

appender: advertised service sends events to receivers
receiver: advertised service receives events from appenders

multicastappender:
_log4j_xml_mcast_appender.local.

multicastreceiver:
_log4j_xml_mcast_receiver.local.

udpappender:
_log4j_xml_udp_appender.local.

udpreceiver:
_log4j_xml_udp_receiver.local.

non-log4j xml socketappender:
_log4j_xml_tcpconnect_appender.local.

xmlsocketreceiver:
_log4j_xml_tcpaccept_receiver.local.

socketappender:
_log4j_obj_tcpconnect_appender.local.

socketreceiver:
_log4j_obj_tcpaccept_receiver.local.

sockethubappender:
_log4j_obj_tcpaccept_appender.local.

sockethubreceiver:
_log4j_obj_tcpconnect_receiver.local.
Comment 4 Scott Deboy 2010-03-16 07:05:24 UTC
While implementing support for the service names in Chainsaw, I realized the MulticastAppender must advertise the multicast address.  To do that, I've added a "multicastAddress" key to the advertised service information.

Also, all xml-based appenders can advertise the fully-qualified class name of the XML encoder that can be used to parse the entries by defining an "encoder" key to the advertised service information.  By default, this isn't needed and the receiver will assume the events are held in an xml fragment conforming to log4j's dtd.
Comment 5 Scott Deboy 2010-03-16 07:45:53 UTC
Correction - the key needed to advertise a specific xml decoder is called 'decoder', not 'encoder'
Comment 6 Scott Deboy 2010-03-17 07:18:07 UTC
Committed to trunk in svn 924176

Commit msg:
Added ZeroConf support to most of the network-based appenders and receivers.

To enable ZeroConf advertising of an appender or receiver, a user can now:
 - add jmdns jar to their classpath
 - set the 'advertiseViaMulticastDNS' param to 'true'

Also added support for discovery of appenders in Chainsaw (Chainsaw will automatically configure a matching receiver when connected).
Supported appenders:
   SocketAppender
   SocketHubAppender (ZeroConfSocketHubAppender is still functional)
   UDPAppender
   MulticastAppender
Supported receivers:
   SocketReceiver
   SocketHubReceiver (also receives events from ZeroConfSocketHubAppender)
   XMLSocketReceiver (can receive events sent over TCP by other logging frameworks)
   UDPReceiver
   MulticastReceiver

Implementation details:
 - removed Zeroconf4log4j class, jmdns access is now through the ZeroConfSupport class (class provides support of JmDNS and ServiceInfo creation via reflection, and supports both jmdns 1.0 and jmdns 3.1 apis)
 - ZeroConfSupport class is now used by ZeroConfSocketHubAppender, Chainsaw and all appenders & receivers that can advertise their configuration via ZeroConf
 - added new 'advertiseViaMulticastDNS' param to the appenders and receivers that support ZeroConf
 - updated the ZeroConf site documentation
 - updated release notes
 - updated the ZeroConfPlugin html file
 - tested appenders with 1.0 and 3.1 jmdns jars
 - updated log4j references in poms to log4j 1.2.16-snapshot where necessary

For those wanting to add ZeroConf support to third-party appenders and have Chainsaw discover the appenders, the service info naming convention is described here: https://issues.apache.org/bugzilla/show_bug.cgi?id=48907