Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 26804 invoked from network); 17 Dec 2004 22:34:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 17 Dec 2004 22:34:21 -0000 Received: (qmail 18933 invoked by uid 500); 17 Dec 2004 22:33:39 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 18867 invoked by uid 500); 17 Dec 2004 22:33:39 -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 18820 invoked by uid 99); 17 Dec 2004 22:33:38 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mailhost.ntl.com (HELO mta10-winn.mailhost.ntl.com) (212.250.162.8) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 17 Dec 2004 14:32:35 -0800 Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20041217223222.JWDR15581.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Fri, 17 Dec 2004 22:32:22 +0000 Received: from [192.168.1.50] (really [81.96.73.108]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20041217223222.SULA769.aamta05-winn.mailhost.ntl.com@[192.168.1.50]> for ; Fri, 17 Dec 2004 22:32:22 +0000 Message-ID: <41C35E7C.60801@chrislambrou.com> Date: Fri, 17 Dec 2004 22:32:28 +0000 From: Chris Lambrou User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N >Someone suggested that for Log, it would be appropriate to make it an >abstract class rather than an interface, so we can make these kinds of >changes easier in the future. I think the risks for this are low, and >probably better [less problems for the majority of users] than just adding >new methods to the existing interface. Other thoughts on this direction? > > I think the risk of annoying quite a number of users by changing Log from an interface to an abstract class is actually quite high. For sure, one of the default logging implementations provided by JCL would probably suffice for the majority. However, there are groups who will have chosen, for whatever reason, to provide their own logging implementations. I've certainly worked on a couple of projects where this has been the case. One of them could probably cope with the change relatively easiliy, but such a change could be a real pain for the other. Whilst the proportion of JCL users in this situation is probably quite small, in terms of actual numbers, such a change could cause quite a lot of grief. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org