You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2005/01/07 20:31:06 UTC
[NEWS] Component and ComponentBase
Curt et al.,
I had a long technical dicussion with a friend who mentioned that in
"Effective Java" Joshua Bloch makes a compelling case against the
setter approach (and in favor of constructors).
The existing configuration code relies on Appenders, Layouts and
Receivers having a default constructor. However, the Component
interface and ComponentBase class do *not* prevent the use of
constructors taking an LR as argument in other classes, in particular
in the classes indirectly instanciated by Appenders, Layouts, etc.
He also suggested a simple solution to the "default repository
configuration while in the context of 'myWebApp'" problem which
triggered all the recent changes. Basically, he suggests that in the
static initializer of LogManager the default repository be configured
before the repositorySelector is instantiated. During the
configuration of the default repository, the repositorySelector
field has to temporarily point to a default RepositorySelector, not
the real selector, not yet instantiated.
This fix may imply that we can go back to the old internal logging
guidelines which only required instance Logger variables, without the
need to change every single class that log4j used internally.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [NEWS] Component and ComponentBase
Posted by Paul Smith <ps...@aconex.com>.
It's an exceptionally good book, definately worth a read.
Ceki Gülcü wrote:
> At 08:50 PM 1/7/2005, you wrote:
>
>> Which item is this in Effective Java? He also makes a strong
>> argument (Item
>> 1) to use static factory methods instead of constructors.
>
>
> Did not read the book yet, so can't tell you.
>
>> I think that going down the constructor path can potentially lead to
>> "parameter madness" as you add more "required" members that must be
>> set at
>> construction time.
>
>
> Yes, absolutely.
>
>> Just a comment,
>> -Mark
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [NEWS] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:50 PM 1/7/2005, you wrote:
>Which item is this in Effective Java? He also makes a strong argument (Item
>1) to use static factory methods instead of constructors.
Did not read the book yet, so can't tell you.
>I think that going down the constructor path can potentially lead to
>"parameter madness" as you add more "required" members that must be set at
>construction time.
Yes, absolutely.
>Just a comment,
>-Mark
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [NEWS] Component and ComponentBase
Posted by Mark Womack <wo...@adobe.com>.
Which item is this in Effective Java? He also makes a strong argument (Item
1) to use static factory methods instead of constructors.
I think that going down the constructor path can potentially lead to
"parameter madness" as you add more "required" members that must be set at
construction time.
Just a comment,
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Friday, January 07, 2005 11:31 AM
> To: Log4J Developers List
> Subject: [NEWS] Component and ComponentBase
>
>
> Curt et al.,
>
> I had a long technical dicussion with a friend who mentioned that in
> "Effective Java" Joshua Bloch makes a compelling case against the
> setter approach (and in favor of constructors).
>
> The existing configuration code relies on Appenders, Layouts and
> Receivers having a default constructor. However, the Component
> interface and ComponentBase class do *not* prevent the use of
> constructors taking an LR as argument in other classes, in particular
> in the classes indirectly instanciated by Appenders, Layouts, etc.
>
> He also suggested a simple solution to the "default repository
> configuration while in the context of 'myWebApp'" problem which
> triggered all the recent changes. Basically, he suggests that in the
> static initializer of LogManager the default repository be configured
> before the repositorySelector is instantiated. During the
> configuration of the default repository, the repositorySelector
> field has to temporarily point to a default RepositorySelector, not
> the real selector, not yet instantiated.
>
> This fix may imply that we can go back to the old internal logging
> guidelines which only required instance Logger variables, without the
> need to change every single class that log4j used internally.
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org