[
https://issues.apache.org/jira/browse/LOG4J2-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Deboy updated LOG4J2-155:
-------------------------------
Attachment: log4j2-155-feb24-rev1.patch
I've reworked the ZeroConf support to implement a new Advertiser interface,
which expects a no-arg constructor to instantiate via reflection, and provides
an advertise method which takes a map of Strings in order to build the
appropriate configuration, as well as an unadvertise method.
I also added a new 'advertiser' configuration attribute, identical to
configurationMonitor, and implemented support for the attribute in the XML and
JSON configuration mechanisms.
The 'advertiser' attribute of the config accepts a fully-qualified class name
which is then constructed using reflection. The default advertiser is a no-op.
I've updated the appenders to take the configuration and exposed the advertiser
from the configuration if the isAdvertise boolean is set to true.
To exercise the logic I have hacked DefaultConfiguration to set the advertiser
to the ZeroConf implementation, and I'm passing that configuration in to the
zeroconf hacked tests in SocketServerTest (which I would of course back
out/tweak prior to final submission).
This design allows the user to provide the ability to turn on or off
advertisement for any supported appender (and possibly other element types if
necessary), and to use ZeroConf or their own mechanism for advertisement.
> add getFormat to Layout
> -----------------------
>
> Key: LOG4J2-155
> URL: https://issues.apache.org/jira/browse/LOG4J2-155
> Project: Log4j 2
> Issue Type: Improvement
> Reporter: Scott Deboy
> Attachments: log4j2-155-feb21-rev1.patch,
> log4j2-155-feb24-rev1.patch, log4j2-155-jan22-rev1.patch,
> log4j2-155-jan23-rev1.patch
>
>
> I was looking at an old rev - getContentType is now exposed - thanks!
> Now if we could add a 'getFormat':
> It would be useful to expose information about a Layout's format.
> If the content type is text/plain, exposing the layout format as a conversion
> pattern would work fine.
> If the content type is text/html or text/xml we could expose something else
> (or null).
> My primary interest is adding the ability to 'discover' the file-based
> logging configurations in order to support them via Chainsaw and multicast
> DNS.
> If all Layouts supporting text/plain content types exposed their format as a
> conversion pattern, and the file-based appenders (optionally) provided the
> ability to advertise their configuration, the files could be remotely tailed
> without the far endpoint even knowing anything about the file configuration.
> For an example, see how multicast appenders are exposed via
> zeroconf/multicast dns in log4j 1.x in activateOptions - something very
> similar could be done with contenttype and format properties in a
> fileappender with a layout.
> if (advertiseViaMulticastDNS) {
> Map properties = new HashMap();
> properties.put("multicastAddress", remoteHost);
> zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
> zeroConf.advertise();
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
