cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] Simplifying component handling
Date Fri, 30 Dec 2005 18:53:52 GMT
Gianugo Rabellino wrote:
> 
> I'm definitely not a fan of constructor injection, exp. when we
> consider how (way too) often we resorted to inheritance in Cocoon
> components. Now, while interface injection is clearly out of fashion,
> sticking with Avalon/Excalibur also means that it would be difficult
> to get around the container (e.g., how do you release components with
> your approach? I assume Excalibur still kinda needs that).
> 
Yes, Excalibur still needs it - but it's easy. Bascially, you "emulate"
the service() method on construction of the object and then you
"emulate" the dispose method when destroying the object. Everything our
ecm++ needs to know is there. As I said, I've done this in Fortress and
we can use that code in ecm++ as well.
And we could implement setter injection with some kind of auto wiring as
well. It's not really that harder. But using setters again requires to
code more than using a constructor.

> 
>>But I think it can even get easier:
>>1. Let's just assume that every component is ThreadSafe - unless
>>otherwise stated - no need to declare the interface anymore. I think
>>apart from the interpreter most components are threadsafe or poolable
>>anyway.
> 
> 
> Again, until Avalon is around I don't see how a marker interface can
> really bug you...
It's not the marker interfaces itself - it's just the amount of code I
have to write. For example, the initializable interface is great - in
other component frameworks you have to configure the init methode
somehow which is imho too much work and makes configuration your
application too complicated.

> 
> 
>>2. Let's remove support for pooled components - yes, seriously. Fiddling
>>with the pool sizes is really annoying. We have a working factory
>>approach for sitemap components, so why not simply use it overall? And
>>rewriting the remaining pooled components shouldn't be that hard. (I now
>>that we are proxying pooled components to simplify the lookup, but you
>>still have to configure pool sizes).
> 
> 
> I'm also still not completely sold on factories. Indeed, they work and
> they're a brilliant solution, but am I the only one smelling hack and
> workaround?
> 
Hmm, don't know :) I don't see a hack/workaround in using factories
instead of using pooled components? If we would use other component
containers we had to do this anyway.

And yes, we have to/want to move away from Avalon - using constructor
injection, removing pooling etc. makes this easier in smaller steps.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message