Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 35950 invoked from network); 14 Dec 2004 01:05:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Dec 2004 01:05:48 -0000 Received: (qmail 29368 invoked by uid 500); 14 Dec 2004 01:05:45 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 29340 invoked by uid 500); 14 Dec 2004 01:05:45 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 29325 invoked by uid 99); 14 Dec 2004 01:05:45 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from out003pub.verizon.net (HELO out003.verizon.net) (206.46.170.103) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 13 Dec 2004 17:05:40 -0800 Received: from [127.0.0.1] ([68.239.103.73]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20041214010538.OBLU1106.out003.verizon.net@[127.0.0.1]> for ; Mon, 13 Dec 2004 19:05:38 -0600 Message-ID: <41BE3C5B.9020401@users.sourceforge.net> Date: Mon, 13 Dec 2004 20:05:31 -0500 From: Matt Sgarlata User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: Enterprise Logging - API Proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.239.103.73] at Mon, 13 Dec 2004 19:05:33 -0600 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ah-hah, I understand our main disconnect now: I'm thinking in terms of configuring logging for an overall application and you're thinking in terms of components. So now at least I understand where you're coming from, but I think it's time for us to agree to disagree :) I think someone said earlier that perhaps part of your proposal would fit better in Log4J or in some other logging component. In any case, thanks for spending so much time discussing your ideas with me. More comments below... Richard Sitze wrote: >Now, were does the *component* developer 'place' this content? I claim we >need a standard approach for this, based on the 'resource bundle name' >parameters we pass into the >EnterpriseLogFactory.getEnterpriseLog(loggerName, resourceBundleName); > > > I think instead of the resourceBundleName we could optionally pass in a MessageSource implementation. That way if internationalization for a component was dependent on a particular implementation, it could be passed in. If no MessageSource was passed in, we could still try java.util.ResourceBundle and the underlying logging implementation. I'm sure we disagree on this point, but I just wanted to through this idea out there :) Matt --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org