Suggesting minor change

[David Sklarew <da...@yahoo.com>]

Sorry for the quoting, I by mistake sent this to the
user list.

David 
--- David Sklarew <da...@yahoo.com> wrote:
> Date: Mon, 15 Jan 2001 07:09:15 -0800 (PST)
> From: David Sklarew <da...@yahoo.com>
> Subject: Suggesting minor change
> To: log4j-user@jakarta.apache.org
> 
> Hi,
>   I am suggesting a very minor change to
> PropertyConfigurator and Category to simplify
> customizing log4J.  The new ability to plugin in
> your
> own Configurator is great.  I know I could extend
> PropertyConfigurator and tell log4j to use my class
> as
> the Configurator, but this change seems like a good
> design decision.
> 
> Suggestion:
> 
> Since there is really strong coupling between the
> Category and Priority sublcasses,
> PropertyConfigurator
> should not call Priority.toPriority(priorityString)
> but instead should call the following new method in
> Category:
> 
>    /*** Set Priority based on string priority
> representation */
>    public void setPriorityString priorityStr) {
>     
> setPriority(MyPriority.toPriority(priorityStr));
>    }
> 
> Reasoning:
> Category has methods insolating users of log4J from
> having to know anything about the Priority class. 
> Why
> should the configuration interface to log4J have to
> know how who is resonsible for creating a Priority
> from a string representation?
> 
> 
> Background:
>    When extending log4J, the PropertyConfigurator
> must
> be subclasses or replaced by a new Configurator to
> enable property file based configuration of
> categories
> using a custom Priority(ie. TRACE).
> 
> Otherwise, the following line in the property config
> file will not work:
> log4j.rootCategory=TRACE, A1
> 
> This is because ProperConfigurator calls method
> parseCategory which calls
> Priority.toPriority(priorityStr).  This method knows
> nothing about the added priority level(s).
> 
> Reasoning for change:
> 
> If a developer wants to add a custom Priority, he
> must
> do the following
> 
> 1) Subclass Priority (ie MyPriority) overriding
> toPriority methods
> 2) Create CategoryFactory, adding
> isCustomPriorityEnabled() method
> 3) Implement a CategoryFactory that instantiates
> MyCategory instances
> 4) Modify PropertyConfigurator (or Priority class)
> so
> that configured categories can be set to new
> priority
> level via config file.
> 
> ---
> Step 4 seems unwarranted.  It does not seem like it
> should be the configurators responsibility to know
> how
> to convert a string to a Priority ( or if it should,
> it could do so using calling methods on a Priority
> instance which could be set as an instance of a
> custom
> priority class.  
> 
> 
> Comments appreciated
> 
> David Sklarew
> david_sklarew@yahoo.com
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail. 
> http://personal.mail.yahoo.com/
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/