Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0DBF6E597 for ; Fri, 18 Jan 2013 02:14:13 +0000 (UTC) Received: (qmail 65295 invoked by uid 500); 18 Jan 2013 02:14:12 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 65229 invoked by uid 500); 18 Jan 2013 02:14:12 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 64954 invoked by uid 99); 18 Jan 2013 02:14:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Jan 2013 02:14:12 +0000 Date: Fri, 18 Jan 2013 02:14:12 +0000 (UTC) From: "Scott Deboy (JIRA)" To: log4j-dev@logging.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (LOG4J2-155) Re-add getContentType, add getFormat to Layout MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Scott Deboy created LOG4J2-155: ---------------------------------- Summary: Re-add getContentType, 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 The different Layout implementations don't expose the contentType previously available in log4j. HTMLLayout has a 'dead' contentType field, but that's it. It would be useful to expose the content type (text/plain, text/html, text/xml) along with a information about the 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