11 messages in org.apache.commons.devRe: [logging] JCL2.0 design - API| From | Sent On | Attachments |
|---|---|---|
| Simon Kitching | Feb 19, 2006 3:29 pm | |
| Boris Unckel | Feb 20, 2006 1:37 am | |
| V. Karthik Kumar | Feb 20, 2006 2:05 am | |
| Emmanuel Bourg | Mar 1, 2006 2:18 am | |
| Craig McClanahan | Mar 1, 2006 9:05 am | |
| Emmanuel Bourg | Mar 1, 2006 9:22 am | |
| Simon Kitching | Mar 1, 2006 11:11 am | |
| Emmanuel Bourg | Mar 2, 2006 1:20 am | |
| Boris Unckel | Mar 2, 2006 3:35 am | |
| Emmanuel Bourg | Mar 2, 2006 6:25 am | |
| Boris Unckel | Mar 2, 2006 6:30 am |
| Subject: | Re: [logging] JCL2.0 design - API | |
|---|---|---|
| From: | Boris Unckel (bori...@gmx.net) | |
| Date: | Feb 20, 2006 1:37:04 am | |
| List: | org.apache.commons.dev | |
Hello,
Simon Kitching wrote:
== LogFactory as factory for Log instances
Currently, JCL uses a LogFactory to create Log instances: Log log = LogFactory.getLog("fff");
By contrast, Log4j has the factory method on the Log class:
Logger log = Logger.getLog("fff");
Having one less class is a *little* nicer for users I think. However it does reduce the flexibility of the system a little and changing this is a major difference from JCL 1.x.
My choice would be: keep LogFactory and LogFactory.getLog as the mechanism for obtaining Log instances.
There is one really big advantage of the current API in this case: If you want to have Logger.getLog("fff") Logger must be a class, currently it is an interface. Please do not switch from an interface to an class, since it is impossible to provide a native implementation of JCL2 without an interface.
Regards Boris