You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2010/03/14 09:33:52 UTC
DO NOT REPLY [Bug 48907] New: Implement zeroconf support for
additional receivers
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
Summary: Implement zeroconf support for additional receivers
Product: Log4j
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Other
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: sdeboy@iname.com
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
Scott Deboy <sd...@iname.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #3 from Scott Deboy <sd...@iname.com> 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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #4 from Scott Deboy <sd...@iname.com> 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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #2 from Scott Deboy <sd...@iname.com> 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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #1 from Scott Deboy <sd...@iname.com> 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?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #5 from Scott Deboy <sd...@iname.com> 2010-03-16 07:45:53 UTC ---
Correction - the key needed to advertise a specific xml decoder is called
'decoder', not 'encoder'
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 48907] Implement zeroconf support for additional
receivers
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48907
--- Comment #6 from Scott Deboy <sd...@iname.com> 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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org