FYI : discussion on containers on the serverside

[Sylvain Wallez <sy...@anyware-tech.com>]

There's an ongoing discussion on TheServerSide about IOC containers : 
PicoContainer, Spring and Avalon :
http://www.theserverside.com/home/thread.jsp?thread_id=20968

A guy from the Spring framework is pushing his baby, and you may want to 
participate to balance the talks.

IOC type 2&3 containers look less intrusive than Avalon, but IMO only 
apply to components having the same lifestyle (and mainly thread safe 
components). Particularily, I don't see how instance pooling can occur 
transparently since there's no lookup/release cycle.

Can someone confirm this ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: discussion on containers on the serverside

[hammett <ho...@cimcorp.com.br>]

After reading a lot of posts I have only one conclusion: I think there is a
spy among us :-)

I didn't know the bean-style approach but doesnt seems robust or with better
performance. Did someone tested the performance between check if a class
implements a specific interface versus looking for a method?

"For wiring up, every Avalon component needs to look up cooperating
components via the Avalon ServiceManager, passed to automatically if it
implements the Serviceable interface. This is very intrusive, as practically
every application component with dependencies has to implement that Avalon
interface."

He's right and I think it hits the Chris Geer's point with "is something
missing?"


Thoughts?

hammett


----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>

> A guy from the Spring framework is pushing his baby, and you may want to
> participate to balance the talks.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org