Alan D. Cabrera wrote:
Bernd Fondermann wrote:
wouldn't it be best to POJO-fy _first_ without a specific container in
mind (a larger task on its own) and then afterwards look at all the
mature containers to integrate with?
My thoughts exactly. IMHO, if the container makes you do weird things
with your design at the start, then it's not a good container.
I agree that we can change but I don't think that Interface Injection
and Service Locator patterns are "weird things".
Webwork, for example, uses this patterns without being tied to a container.
I think that using "AwareInterfaces" in addiction to setter injection
helps developers (help IDEs to provide better code browsing) and doesn't
bind me to something specific.
A modern pojo container should not have problems if my POJO implements
interfaces.
for example the parent class hiearchie for core components like
org.apache.james.James is based on classes like
org.apache.avalon.framework.logger.LogEnabled.
IMHO, to put it politely, yuck. This is an example of why container
software should not be so invasive in your code. To be sure Avalon was
on the cutting edge and investigated a lot of good ideas. I think that
we've learned a bit since then.
LogEnabled is simply an interface that says that the component has an
"enableLogging(Logger l)" method. Nothing else.
If you refactor it to "setLogger(Logger l)" is a standard setter DI way
to componentize logging management.
LogEnabled provides functionality for what is called an 'aspect'
today. modern IoC frameworks weave those aspects into the components
by 'crosscutting' them - the component has no direct notion of it
happening.
this and similar refactoring steps would make James components much
more POJOs and thus more easily portable into new containers.
I am of the same opinion.
I this I'm reading most projects using many components finish up
creating their own Logger interface and creating wrappers for the
variour components so to have a centralized way to receive logs.
This is IoC applied to logging, nothing more.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
