Stefano Bagnara wrote:
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.
I think that we agree here. What I was thinking was if we had to add
interfaces from external containers to the core code, that would be bad.
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.
As mentioned above, it's the inclusion of external container code into
the James server core code that I object to. I'll explain why below.
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.
When we were looking for an ORB for Geronimo, I tried to embed OpenORB.
This project uses Avalon. Because Avalon courses through the veins of
every aspect of OpenORB, it was impossible to embed an ORB into Geronimo
w/out bringing in everything but the kitchen sink.
I think that we're saying the same thing and that we are narrowing
things down to common terms. Do you agree?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
