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/03 18:39:00 UTC
[POLL] Component and ComponentBase
Anybody think it is a bad idea? If yes, any alternatives?
At 06:35 PM 1/3/2005, ceki@apache.org wrote:
>ceki 2005/01/03 09:35:26
>
> Modified: src/java/org/apache/log4j AppenderSkeleton.java
> Appender.java
> Added: src/java/org/apache/log4j/spi Component.java
> ComponentBase.java
> Log:
> - Log4j interfaces implement o.a.l.spi.Component and base classes
> extend ComponentBase. Started by changing the Appender interface and
> AppenderSkeleton class,
> other changes wil follow.
> --
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
[HEADS UP] New internal logging guidelines
Posted by Ceki Gülcü <ce...@qos.ch>.
Updated http://www.qos.ch/logging/internalLogging.jsp with the new guidelines.
--
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: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
Component and ComponentBase are indeed generic names. However, these
classes are not for public consumption. They are intended to be used
*internally* by log4j components (Appenders, Layouts, Filters, Receivers,
ConnectionSources, etc.).
At 06:49 PM 1/3/2005, Yoav Shapira wrote:
>Hi,
>I don't think it's a bad idea, but could there be a more specific or
>domain-related name for it? Component(Base) is very generic, whereas
>Appender(Skeleton) is more logging-domain-specific.
>
>Yoav
--
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: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
Sounds reasonable.
At 06:00 PM 1/5/2005, you wrote:
>At this point, the [POLL] in the subject is misleading since the changes
>have been started (possibly finished) in the CVS due to an accidental
>build breakage when some of the changes slipped in. I don't think anyone
>is advocating backing them out, but I do have reservations that I haven't
>had time to investigate. At this time, I think the most effective path
>forward is to review Ceki's changes once they have been fully committed
>and raise concrete proposals for change on the mailing list.
--
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: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
At this point, the [POLL] in the subject is misleading since the
changes have been started (possibly finished) in the CVS due to an
accidental build breakage when some of the changes slipped in. I don't
think anyone is advocating backing them out, but I do have reservations
that I haven't had time to investigate. At this time, I think the most
effective path forward is to review Ceki's changes once they have been
fully committed and raise concrete proposals for change on the mailing
list.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
Mark,
As I understand it, a marker interface does not have methods. Since
Component has one method, namely setLoggerRepository(), it is not a
marker interface by definition.
The Appender interface extends the Component interface. So when you
get a handle on an object implementing the Appender interface, you
know that you can safely invoke setLoggerRepository() on that
object. Had Appender not been an extension of the Component interface
but AppenderSkeleton still extended ComponentBase, the compiler would
not have allowed you to write:
void foo(String className) {
Appender appender = (Appender) instantiateByReflection(className);
appender.setLoggerRepository(repository) <-- would not compile
}
The Component interface must exist and Appender must extend Component,
so that we can invoke the setLoggerRepository() method on appender
instances, a condition imposed by the Java compiler.
A bunch of log4j classes invoke Component.setLoggerRepository. To
convince yourself, if you are using Eclipse, select the
setLoggerRepository and right click, and then select
References->Project. You should see about 20 points where the project
references Component.setLoggerRepository().
Previously, appenders did not need to know about their owning
repository because the repository did not provide services beyond
returning logger instances. Appenders did not care about loggers and
hence did not need to hold a reference to their owning repository. In
1.3 however, the repository manages repository-wide properties, it
holds objects shared by embedded components, it holds a reference to
the scheduler, plug-in registry, etc. There is also the question of
self-generated log messages.
Concerning the impact on existing Appenders developed outside Apache
Logging Services, since they all derive from AppenderSkeleton, their
source code will NOT require changes. However, they might need to be
recompiled against 1.3. After verification, I appears that existing
Appender will run fine with 1.3. No need to recompile.
In principle though we have no obligation to keep our internal
interfaces backward compatible. One can argue all day about how good,
how nice and how important backward compatibility is, but when push
comes to shove, it is even more important to keep expectations
realistic and be able to deliver on them.
For instance, when a committer makes changes to code, I expect them
to check that he did not break our test cases by running "ant runAll"
in the ./tests/ directory.
At 02:54 AM 1/5/2005, Mark Womack wrote:
> > No, log4j objects will not be referenced as Component. It is not a
> > marker interface either.
> >
> > The requirement to have both Component as an interface and
> > ComponentBase as a class, stems from the fact that we make the
> > distinction between Appender the interface and AppenderSkeleton the
> > class. Implementations of Appender derive from AppenderSkeleton but
> > all the other code in log4j refers to Appender and is oblivious to the
> > existence of AppenderSkeleton.
>
>And that makes sense because you want the outside world to deal with
>Appender, not AppenderSkeleton. AppenderSkeleton has implementation methods
>that are specific to it. I get it. But if we will never reference
>Components and it is not a marker interface, why have an interface at all?
>Why not just implement ComponentBase with the functionality and have all the
>log4j implementation just inherit from that base class? What purpose is the
>Component interface serving here?
>
>Let's approach it a different way. If I am a developer, and I implement my
>own appender class that implements the Appender interface, will we (the
>framework) care if I implement setLoggerRepository? Will parts of the
>framework expect to find this method or crash otherwise? If yes, then an
>interface makes sense here. If no, then I don't see what purpose the
>interface really serves; ComponentBase is providing useful but not required
>functionality for internal logging.
>
>I am guessing that we are making setLoggerRepository a required method for
>appenders given that you have Appender extending Component. How have
>appenders survived this long without knowing about their owning repository?
>Besides internal logging (which one might argue, external developers should
>not have to be concerned about), what benefit does this have for appenders?
>
>That interface change is going to have much larger effect than the change to
>the Configurator interface. Almost no one writes their own configurator,
>but at some point almost everyone writes their own appender. Unless they
>subclass AppenderSkeleton, they will need to modify their appender code.
>
>-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 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
[NEWS] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
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: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
Curt,
It is not only a question of timing or opportunity.
IMHO, the advantages of constructor injection over interface
dependency injector are minor. I am understandably not very keen on
going through yet another series of pervasive changes in order to eke
out a delta.
Not only that, we already have a well established pattern for
component initialization and configuration model.
Component c = new Component();
c.setProperty1(...);
c.setProperty2(...);
...
c.setPropertyN(...);
c.activateOptions();
or its variant using reflexion:
Component c = Classs.forName("some.class.name").newInstance();
c.setProperty1(...);
c.setProperty(...);
...
c.setPropertyN(...);
c.activateOptions();
(The above show the gist of the pattern, the actual code contains
some defensive elements.)
This pattern is a little verbose but extremely generic in the sense
that it can deal with all appender types, layout types or receiver
types. This is quite fundamental point. Here you have a pattern which
offers authors of components a way to deal with any variation in the
set of properties passed to the component and still obtain a
functioning component at the end, plus a well-defined error model.
This pattern is expected to correctly handle any future component type
what we may concoct in the future. Having spent the last two years
trying to get rid of non-default constructors in log4j components, I
do not wish to see them come back through other means. Constructor
injection was tried in the past but does not fit with the current
component configuration model.
If what you have in mind is more radical than I'd be very interested
in continuing this discussion. However, if it is only personal
preference of:
Component c = Component(repository);
c.setProperty1(...);
c.setProperty(...);
...
c.setPropertyN-1(...);
c.activateOptions();
over:
Component c = Component();
c.setProperty1(...);
c.setProperty(...);
...
c.setPropertyN(...);
c.activateOptions();
then, please take into account the large body of existing code before
pursuing this issue any further.
At 05:00 AM 1/7/2005, Curt Arnold wrote:
>On Jan 6, 2005, at 4:15 PM, Ceki Gülcü wrote:
>
>>>I'd still like to see LoggerRepositoryAware disappear in favor of
>>>passing in the LoggerRepository in the constructor, but would not do
>>>that just at this moment.
>>
>>This reminds me of "Forms Of Dependency Injection"
>>
>>http://www.martinfowler.com/articles/
>>injection.html#FormsOfDependencyInjection
>
>Good summary of the issue. The current form is a interface dependency
>injector, I'd favor constructor dependency injector. The constructor
>dependency injector would be require more pervasive code changes,
>basically adding a LoggerRepository param to constructors that derive
>from ComponentBase. However, it would prevent having to deal with
>constructed by not setLoggerRepository'd objects. If the "assembler"
>code that constructs and initializes the object is not replicated all
>over the code base, then it would fairly simple to change forms when
>things settle down a bit.
--
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: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
On Jan 6, 2005, at 4:15 PM, Ceki Gülcü wrote:
>> I'd still like to see LoggerRepositoryAware disappear in favor of
>> passing in the LoggerRepository in the constructor, but would not do
>> that just at this moment.
>
> This reminds me of "Forms Of Dependency Injection"
>
> http://www.martinfowler.com/articles/
> injection.html#FormsOfDependencyInjection
>
Good summary of the issue. The current form is a interface dependency
injector, I'd favor constructor dependency injector. The constructor
dependency injector would be require more pervasive code changes,
basically adding a LoggerRepository param to constructors that derive
from ComponentBase. However, it would prevent having to deal with
constructed by not setLoggerRepository'd objects. If the "assembler"
code that constructs and initializes the object is not replicated all
over the code base, then it would fairly simple to change forms when
things settle down a bit.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:02 PM 1/6/2005, Curt Arnold wrote:
>Would like Appender and other existing interfaces to NOT extend
>LoggerRepositoryAware.
>
>I'd still like to see LoggerRepositoryAware disappear in favor of passing
>in the LoggerRepository in the constructor, but would not do that just at
>this moment.
This reminds me of "Forms Of Dependency Injection"
http://www.martinfowler.com/articles/injection.html#FormsOfDependencyInjection
>The implementation of setLoggerRepository should allow multiple calls as
>long as the repository doesn't change. That is:
>
>-if (this.repository == null)
>+if(this.repository == null || this.repository == repository)
Very good point.
--
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: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
+1 on rename of Component to LoggingRepositoryAware.
Don't like LRABase, okay with ComponentBase, LoggerComponentBase or
LoggingComponentBase.
Would like Appender and other existing interfaces to NOT extend
LoggerRepositoryAware.
I'd still like to see LoggerRepositoryAware disappear in favor of
passing in the LoggerRepository in the constructor, but would not do
that just at this moment.
The implementation of setLoggerRepository should allow multiple calls
as long as the repository doesn't change. That is:
-if (this.repository == null)
+if(this.repository == null || this.repository == repository)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Paul Smith <ps...@aconex.com>.
I think what Mark was saying was correct, in that the base/abstract
class could end up supporting more than just that the *Aware interface,
so the name of the base class should not be tied to one specific
interface name. ComponentBase is not a bad choice if it wasn't for the
fact that there is so many things named with Component these days, and
given this is strictly related to Logging components it might benefit
from a tighter name.
So I'm only on the - side of something starting with Component* because
that would make finding it in Open Type a little harder than I would
like. :D (probably not a very good reason I know).
cheers,
Paul Smith
Ceki Gülcü wrote:
> At 09:04 PM 1/6/2005, you wrote:
>
>> +1 too, that's a nice specific name. Still not too happy with
>> ComponentBase though. LoggingComponentBase?
>
>
> How about LRAwareBase?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:04 PM 1/6/2005, you wrote:
>+1 too, that's a nice specific name. Still not too happy with
>ComponentBase though. LoggingComponentBase?
How about LRAwareBase?
--
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: [POLL] Component and ComponentBase
Posted by Paul Smith <ps...@aconex.com>.
+1 too, that's a nice specific name. Still not too happy with
ComponentBase though. LoggingComponentBase?
Ceki Gülcü wrote:
> +1 to LoggerRepositoryAware.
>
> At 06:13 PM 1/6/2005, you wrote:
>
>> How about "LoggerRepositoryAware" for the name of the interface? This
>> follows the pattern the Spring framework uses to name interfaces that
>> define
>> allowed setter methods (ie ApplicationContextAware interface defines a
>> method setApplicationContext(ApplicationContext ac)).
>>
>> ComponentBase could still be there. In the future it could implement
>> other
>> needed/required interfaces.
>>
>> -Mark
>>
>> > -----Original Message-----
>> > From: Paul Smith [mailto:psmith@aconex.com]
>> > Sent: Tuesday, January 04, 2005 1:07 PM
>> > To: Log4J Developers List
>> > Subject: Re: [POLL] Component and ComponentBase
>> >
>> >
>> > > The requirement to have both Component as an interface and
>> > > ComponentBase as a class, stems from the fact that we make the
>> > > distinction between Appender the interface and AppenderSkeleton the
>> > > class. Implementations of Appender derive from AppenderSkeleton but
>> > > all the other code in log4j refers to Appender and is oblivious
>> to the
>> > > existence of AppenderSkeleton.
>> > >
>> > One of the standards I've seen (and yes there are many) is to have the
>> > abstract base class providing implemented methods to assist
>> sub-classes
>> > is to name it Abstract<InterfaceName>. This appears to be a common
>> > approach and I would put forward to the group. *Base is fine, just
>> > thought I'd mention that.
>> >
>> > I would be -0.25 on the choice of "Component*" however. If this is
>> > truely only designed to be used by log4j internals then I think we
>> > should appropriately name it. As others have mentioned Component by
>> > itself is far too generic (do an Open Type search in Eclipse for
>> > Component and you'll see what I mean). How about LoggingComponent and
>> > LoggingComponentBase or derivations thereof?
>> >
>> > cheers,
>> >
>> > Paul Smith
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
+1 to LoggerRepositoryAware.
At 06:13 PM 1/6/2005, you wrote:
>How about "LoggerRepositoryAware" for the name of the interface? This
>follows the pattern the Spring framework uses to name interfaces that define
>allowed setter methods (ie ApplicationContextAware interface defines a
>method setApplicationContext(ApplicationContext ac)).
>
>ComponentBase could still be there. In the future it could implement other
>needed/required interfaces.
>
>-Mark
>
> > -----Original Message-----
> > From: Paul Smith [mailto:psmith@aconex.com]
> > Sent: Tuesday, January 04, 2005 1:07 PM
> > To: Log4J Developers List
> > Subject: Re: [POLL] Component and ComponentBase
> >
> >
> > > The requirement to have both Component as an interface and
> > > ComponentBase as a class, stems from the fact that we make the
> > > distinction between Appender the interface and AppenderSkeleton the
> > > class. Implementations of Appender derive from AppenderSkeleton but
> > > all the other code in log4j refers to Appender and is oblivious to the
> > > existence of AppenderSkeleton.
> > >
> > One of the standards I've seen (and yes there are many) is to have the
> > abstract base class providing implemented methods to assist sub-classes
> > is to name it Abstract<InterfaceName>. This appears to be a common
> > approach and I would put forward to the group. *Base is fine, just
> > thought I'd mention that.
> >
> > I would be -0.25 on the choice of "Component*" however. If this is
> > truely only designed to be used by log4j internals then I think we
> > should appropriately name it. As others have mentioned Component by
> > itself is far too generic (do an Open Type search in Eclipse for
> > Component and you'll see what I mean). How about LoggingComponent and
> > LoggingComponentBase or derivations thereof?
> >
> > cheers,
> >
> > Paul Smith
> >
> > ---------------------------------------------------------------------
> > 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
--
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: [POLL] Component and ComponentBase
Posted by Mark Womack <wo...@adobe.com>.
How about "LoggerRepositoryAware" for the name of the interface? This
follows the pattern the Spring framework uses to name interfaces that define
allowed setter methods (ie ApplicationContextAware interface defines a
method setApplicationContext(ApplicationContext ac)).
ComponentBase could still be there. In the future it could implement other
needed/required interfaces.
-Mark
> -----Original Message-----
> From: Paul Smith [mailto:psmith@aconex.com]
> Sent: Tuesday, January 04, 2005 1:07 PM
> To: Log4J Developers List
> Subject: Re: [POLL] Component and ComponentBase
>
>
> > The requirement to have both Component as an interface and
> > ComponentBase as a class, stems from the fact that we make the
> > distinction between Appender the interface and AppenderSkeleton the
> > class. Implementations of Appender derive from AppenderSkeleton but
> > all the other code in log4j refers to Appender and is oblivious to the
> > existence of AppenderSkeleton.
> >
> One of the standards I've seen (and yes there are many) is to have the
> abstract base class providing implemented methods to assist sub-classes
> is to name it Abstract<InterfaceName>. This appears to be a common
> approach and I would put forward to the group. *Base is fine, just
> thought I'd mention that.
>
> I would be -0.25 on the choice of "Component*" however. If this is
> truely only designed to be used by log4j internals then I think we
> should appropriately name it. As others have mentioned Component by
> itself is far too generic (do an Open Type search in Eclipse for
> Component and you'll see what I mean). How about LoggingComponent and
> LoggingComponentBase or derivations thereof?
>
> cheers,
>
> Paul Smith
>
> ---------------------------------------------------------------------
> 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
Re: [POLL] Component and ComponentBase
Posted by Paul Smith <ps...@aconex.com>.
> The requirement to have both Component as an interface and
> ComponentBase as a class, stems from the fact that we make the
> distinction between Appender the interface and AppenderSkeleton the
> class. Implementations of Appender derive from AppenderSkeleton but
> all the other code in log4j refers to Appender and is oblivious to the
> existence of AppenderSkeleton.
>
One of the standards I've seen (and yes there are many) is to have the
abstract base class providing implemented methods to assist sub-classes
is to name it Abstract<InterfaceName>. This appears to be a common
approach and I would put forward to the group. *Base is fine, just
thought I'd mention that.
I would be -0.25 on the choice of "Component*" however. If this is
truely only designed to be used by log4j internals then I think we
should appropriately name it. As others have mentioned Component by
itself is far too generic (do an Open Type search in Eclipse for
Component and you'll see what I mean). How about LoggingComponent and
LoggingComponentBase or derivations thereof?
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [POLL] Component and ComponentBase
Posted by Mark Womack <wo...@adobe.com>.
> No, log4j objects will not be referenced as Component. It is not a
> marker interface either.
>
> The requirement to have both Component as an interface and
> ComponentBase as a class, stems from the fact that we make the
> distinction between Appender the interface and AppenderSkeleton the
> class. Implementations of Appender derive from AppenderSkeleton but
> all the other code in log4j refers to Appender and is oblivious to the
> existence of AppenderSkeleton.
And that makes sense because you want the outside world to deal with
Appender, not AppenderSkeleton. AppenderSkeleton has implementation methods
that are specific to it. I get it. But if we will never reference
Components and it is not a marker interface, why have an interface at all?
Why not just implement ComponentBase with the functionality and have all the
log4j implementation just inherit from that base class? What purpose is the
Component interface serving here?
Let's approach it a different way. If I am a developer, and I implement my
own appender class that implements the Appender interface, will we (the
framework) care if I implement setLoggerRepository? Will parts of the
framework expect to find this method or crash otherwise? If yes, then an
interface makes sense here. If no, then I don't see what purpose the
interface really serves; ComponentBase is providing useful but not required
functionality for internal logging.
I am guessing that we are making setLoggerRepository a required method for
appenders given that you have Appender extending Component. How have
appenders survived this long without knowing about their owning repository?
Besides internal logging (which one might argue, external developers should
not have to be concerned about), what benefit does this have for appenders?
That interface change is going to have much larger effect than the change to
the Configurator interface. Almost no one writes their own configurator,
but at some point almost everyone writes their own appender. Unless they
subclass AppenderSkeleton, they will need to modify their appender code.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:27 PM 1/4/2005, Mark Womack wrote:
>Not a bad idea per se, but what is the motivation with making it an
>interface? Will the outside world need to know about the Component
>interface in any way? Do we intend to reference log4j objects as Component
>or maybe use it as a marker interface?
No, log4j objects will not be referenced as Component. It is not a
marker interface either.
The requirement to have both Component as an interface and
ComponentBase as a class, stems from the fact that we make the
distinction between Appender the interface and AppenderSkeleton the
class. Implementations of Appender derive from AppenderSkeleton but
all the other code in log4j refers to Appender and is oblivious to the
existence of AppenderSkeleton.
>If we just need this internally for log4j then we could just add it as a
>method on ComponentBase, and be done with it. If we want external
>developers to code their implementations to include this method (and not be
>required to extend ComponentBase or AppenderSkeleton), then having it in an
>interface makes sense.
?
ComponentBase is just an implementation of the Component interface.
>I'm all for having interfaces instead of concrete parent classes, but just
>having an interface to have an interface is my question.
Good question. However, the same question can be asked about Appender
the interface and AppenderSkeleton the class.
>-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: [POLL] Component and ComponentBase
Posted by Mark Womack <wo...@adobe.com>.
Not a bad idea per se, but what is the motivation with making it an
interface? Will the outside world need to know about the Component
interface in any way? Do we intend to reference log4j objects as Component
or maybe use it as a marker interface?
If we just need this internally for log4j then we could just add it as a
method on ComponentBase, and be done with it. If we want external
developers to code their implementations to include this method (and not be
required to extend ComponentBase or AppenderSkeleton), then having it in an
interface makes sense.
I'm all for having interfaces instead of concrete parent classes, but just
having an interface to have an interface is my question.
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Monday, January 03, 2005 9:39 AM
> To: Log4J Developers List; logging-log4j-cvs@apache.org
> Subject: [POLL] Component and ComponentBase
>
>
> Anybody think it is a bad idea? If yes, any alternatives?
>
> At 06:35 PM 1/3/2005, ceki@apache.org wrote:
> >ceki 2005/01/03 09:35:26
> >
> > Modified: src/java/org/apache/log4j AppenderSkeleton.java
> > Appender.java
> > Added: src/java/org/apache/log4j/spi Component.java
> > ComponentBase.java
> > Log:
> > - Log4j interfaces implement o.a.l.spi.Component and base classes
> > extend ComponentBase. Started by changing the Appender interface and
> > AppenderSkeleton class,
> > other changes wil follow.
> > --
>
> 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
Re: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:39 PM 1/3/2005, Curt Arnold wrote:
>On Jan 3, 2005, at 11:49 AM, Yoav Shapira wrote:
>
>>Hi,
>>I don't think it's a bad idea, but could there be a more specific or
>>domain-related name for it? Component(Base) is very generic, whereas
>>Appender(Skeleton) is more logging-domain-specific.
>>
>>Yoav
>>
>>--- Ceki Gülcü <ce...@qos.ch> wrote:
>
>The only method on o.a.l.spi.Component is setLoggerRepository. I assume
>the motivation is to inform "components" of which LoggerRepository they
>belong after their construction. I haven't looked at the problem. but my
>preference would be to modify the respective constructors to take either a
>LoggerRepository (assuming that it would be known at construction time) or
>something like a LoggerRepositoryLocator which could be used to locate the
>repository at a later time. Changing the constructors would force
>propagation of the LoggerRepository. The setLoggerRepository approach
>leaves the potential to forget to set the repository.
You are 100% right to note that LoggerRepository can be left
unset. However, leaving the LoggerRepository unset is synonymous with
a programming error. In the absence of bugs in log4j configurators,
the LoggerRepository will be correctly set for all components
generated during the configuration phase. If custom extensions (built
outside the Apache Logging Services) forget to set the
LoggerRepository, then the CustomerBase implementation defaults to
using a o.a.ugli.impl.SimpleLoggerFA instance instead of the "correct"
LoggerRepository.
Most importantly, it is not possible to impose a constructor on an
interface and log4j source code assumes interfaces, not classes. For
example, the code is developed in terms of the Appender interface not
AppenderSkeleton.
>Could you describe the items that should be aware of the LoggerRepository?
Basically, all components that may generate log4j *internal* log
messages must be aware of their owning LoggerRepository.
--
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: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
On Jan 4, 2005, at 6:08 AM, Ceki Gülcü wrote:
> At 08:53 PM 1/3/2005, Curt Arnold wrote:
>> In addition, it is probably not good to have "components" reference
>> the concrete LoggerRepository class. We should probably introduce an
>> interface (maybe "LoggerContext") that exposes the methods on
>> LoggerRepository that "components" are expected to use.
>
> This touches a larger problem of log4j's security model. However,
> since log4j users can freely access the logger repository it would
> seem unreasonable to prevent log4j components from having the same
> access.
>
I was thinking more about testing concerns than security concerns. If
"components" depend on and may have interactions with a concrete class
like LoggerRepository, then it increases the difficulty of testing. If
they depend on an interface, then the unit tests can provide a mock
implementation if need be.
> You are 100% right to note that LoggerRepository can be left
> unset. However, leaving the LoggerRepository unset is synonymous with
> a programming error.
Minimizing the opportunities for programming errors is a good thing in
my book.
> In the absence of bugs in log4j configurators,
> the LoggerRepository will be correctly set for all components
> generated during the configuration phase. If custom extensions (built
> outside the Apache Logging Services) forget to set the
> LoggerRepository, then the CustomerBase implementation defaults to
> using a o.a.ugli.impl.SimpleLoggerFA instance instead of the "correct"
> LoggerRepository.
>
> Most importantly, it is not possible to impose a constructor on an
> interface and log4j source code assumes interfaces, not classes. For
> example, the code is developed in terms of the Appender interface not
> AppenderSkeleton.
The configuration constructs concrete classes and could pass the
LoggerRepository/LoggerContext/Logger as a constructor parameter.
Looks like the move to extend things from ComponentBase is in progress.
Please give us a heads up when that is finished. I would very
strongly prefer that the "component" receive an implementation of some
appropriate interface instead of a concrete class and would prefer that
that occur in its constructor. When you've rebased everything on
ComponentBase, then we can experiment.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:53 PM 1/3/2005, Curt Arnold wrote:
>In addition, it is probably not good to have "components" reference the
>concrete LoggerRepository class. We should probably introduce an
>interface (maybe "LoggerContext") that exposes the methods on
>LoggerRepository that "components" are expected to use.
This touches a larger problem of log4j's security model. However,
since log4j users can freely access the logger repository it would
seem unreasonable to prevent log4j components from having the same
access.
--
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: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
In addition, it is probably not good to have "components" reference the
concrete LoggerRepository class. We should probably introduce an
interface (maybe "LoggerContext") that exposes the methods on
LoggerRepository that "components" are expected to use.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Curt Arnold <ca...@apache.org>.
On Jan 3, 2005, at 11:49 AM, Yoav Shapira wrote:
> Hi,
> I don't think it's a bad idea, but could there be a more specific or
> domain-related name for it? Component(Base) is very generic, whereas
> Appender(Skeleton) is more logging-domain-specific.
>
> Yoav
>
> --- Ceki Gülcü <ce...@qos.ch> wrote:
>
The only method on o.a.l.spi.Component is setLoggerRepository. I
assume the motivation is to inform "components" of which
LoggerRepository they belong after their construction. I haven't
looked at the problem. but my preference would be to modify the
respective constructors to take either a LoggerRepository (assuming
that it would be known at construction time) or something like a
LoggerRepositoryLocator which could be used to locate the repository at
a later time. Changing the constructors would force propagation of the
LoggerRepository. The setLoggerRepository approach leaves the
potential to forget to set the repository.
Could you describe the items that should be aware of the
LoggerRepository?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [POLL] Component and ComponentBase
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
I don't think it's a bad idea, but could there be a more specific or
domain-related name for it? Component(Base) is very generic, whereas
Appender(Skeleton) is more logging-domain-specific.
Yoav
--- Ceki G�lc� <ce...@qos.ch> wrote:
>
> Anybody think it is a bad idea? If yes, any alternatives?
>
> At 06:35 PM 1/3/2005, ceki@apache.org wrote:
> >ceki 2005/01/03 09:35:26
> >
> > Modified: src/java/org/apache/log4j AppenderSkeleton.java
> > Appender.java
> > Added: src/java/org/apache/log4j/spi Component.java
> > ComponentBase.java
> > Log:
> > - Log4j interfaces implement o.a.l.spi.Component and base classes
> > extend ComponentBase. Started by changing the Appender interface and
> > AppenderSkeleton class,
> > other changes wil follow.
> > --
>
> 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