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? We should go over it once again, maybe. I have a "Poolable considered harmful" RT brewing somewhere in the back of my head ;-).
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.
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].
Just check that no subclasses exist that need it. Eclipse should tell you ;-)
Done already, thanks.
Ugo
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107640905422462&w=2 [2] http://paulhammant.com/blog//000241.html
