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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
