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" class="..."/>
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] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107640905422462&w=2 [2] http://paulhammant.com/blog//000241.html
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
