logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-155) add getFormat to Layout
Date Fri, 22 Feb 2013 03:18:12 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583870#comment-13583870
] 

Scott Deboy commented on LOG4J2-155:
------------------------------------

MulticastDNS/Bonjour/Rendezvous/ZeroConf is useful when you don't want or need central infrastructure
- it is more for ad hoc discovery.  With mDNS there is no central server to manage, you just
have to be able to see the discovery messages on your local network in order to take advantage
of the advertised service.

You bring up an important point that I should abstract the 'advertisement' away from one specific
implementation (ZeroConf).  The plumbing/data necessary in order to actually automate things
is still necessary, but the fact that it is advertised via ZeroConf, or a custom database,
or something else, is a good point - particularly when the infrastructure that is doing the
advertising isn't accessible via multicast to the endpoint needing to use the advertisement.

I will work on adding a layer of abstraction there - if you have any suggestions let me know.
 I plan on only mapping ZeroConf discovery initially, but I definitely see value there.

Scott
                
> 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-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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message