Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4406B8E8.3030605@apache.org>
Date: Thu, 02 Mar 2006 10:20:40 +0100
From: Emmanuel Bourg <ebourg@apache.org>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [logging] JCL2.0 design - API
References: <1140391781.3813.150.camel@localhost.localdomain>
	 <43F98DD7.6050104@gmx.net>
 <44057514.4040209@apache.org>	 <f8b39ace0603010905v286e6030l24b501bccb0fc2be@mail.gmail.com>
	 <4405D862.7000008@apache.org>
 <1141240299.3812.12.camel@localhost.localdomain>
In-Reply-To: <1141240299.3812.12.camel@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Simon Kitching wrote:
> Fascinating! I haven't seen that trick before. An interface containing a
> static method (via a little indirection)...cool.
> 
> Are you serious about this proposed API for the Log class, though?
> 
> I'm hoping that people will agree that the current Log API is ok (even
> if it isn't 100% perfect), as that makes 2.x more backwards-compatible.
> However if a change is made, I think it would make more sense to move to
> the j.u.l/log4j solution (Log is abstract class) rather than invent yet
> another design. However if you think 
>   Log.Factory.getLog("foo")
> really should be considered then we can start debating pros/cons.

I just wanted to mention this solution if Log had to remain an 
interface, but I won't support it. I prefer to turn Log into an abstract 
class.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org