cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Simplifying component handling
Date Fri, 30 Dec 2005 18:37:27 GMT
On 12/30/05, Carsten Ziegeler <> wrote:

> Aren't you tired of implementing a service/dispose combo for each of
> your components over and over again? Now, actually, I am. Big time.
> Way too much code me thinks. So what about:
> class MyComponent implements SOMETHING, ThreadSafe {
>   protected final ClassA compA;
>   protected final ClassB compB;
>   public MyComponent(ClassA a, ClassB b) {
>     compA = a;
>     compB = b;
>   }
> }

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).

> 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...

> 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

> My final idea is to use even more magic (but it might be too much magic?):
> class MyComponent implements SOMETHING {
>   protected final ClassA component_A;
>   protected final ClassB component_B;
> }
> When the component is instantiated all instance variables prefixed with
> "component_" are setup using some injection mechanism - or perhaps using
> annotations?

Yes, that's definitely too much magic. ;-) I'd rather favor an
annotation/attribute based approach rather than reflection hacks...


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:
(blogging at

View raw message