cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Serviceable considered harmful (was Re: XSP not working in CVS head?)
Date Mon, 17 May 2004 15:40:12 GMT
Ugo Cei wrote:

> Sylvain Wallez wrote:
>> I agree with this. Now IOC type 2/3 containers haven't solved the 
>> problem of non thread-safe components, and more generally relations 
>> between components of different lifestyles (e.g. ThreadSafe and 
>> Poolable). And Cocoon cannot live without this, unless some major 
>> refactoring leading to Cocoon 3
>> Also, how do IOC type 2/3 containers handle optional dependencies 
>> (e.g. TraxTransformer checking for the Deli component) ?
>> Finally, what frightens me with Spring configuration is the need to 
>> explicitely declare all dependencies. Imagine the size of a 
>> Spring-style cocoon.xconf...
> Mind you, I've just started to dip my toes into Spring's waters. I'm 
> just a newbie there, but I was already alert about the issues you 
> mention. I hope to dive deeper into it soon.
> WRT Poolable, wasn't you who started a thread titled "[RT] 
> Alternatives to Poolable" [1] some time ago?

Yes ;-) This has been on my wishlist for years (since I started working 
on Cocoon for small systems) but leads to some major changes in the 
whole pipeline stuff...

> We should go over it once again, maybe. I have a "Poolable considered 
> harmful" RT brewing somewhere in the back of my head ;-).

Write it down ;-)

> And for the size of a "Springized" cocoon.xconf: yes, you'd need to 
> declare them there (unless your beans implement the BeanFactoryAware 
> interface, which serves the same purpose as Serviceable, AFAIU, but 
> it's not the only possibility) but maybe we could factor it into 
> smaller files. Each *real* block should come with its own 
> configuration, for instance.

Makes me think: does Spring has the concept of "default component"? i.e. 
a bean that will be injected for dependencies of a given type that 
aren't explicitely written in the configuration file.

<bean name="parser" default-impl-of="org.apache.excalibur.xml.Parser" 

> And finally, yes, this would be the subject of some major refactoring 
> leading to Cocoon 3.
>> Is this really an aspect, when components cannot live without it 
>> (because they do produce specific error messages)? IMO, it's more a 
>> component dependency, but a crucial one as it must occur in the early 
>> stages of component setup. A good candidate for constructor injection.
> +1 for constructor injection, but see also this [2].

IIRC Paul proposed this a long time ago on Avalon-dev. I don't like it, 
as it requires yet-another-interface and at least two implementations (a 
logging one and an empty one) to be really useful. 3 classes for 
logging! Do you know someone that will do that?

> [1]
> [2]


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message