Guido Casper wrote:
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get configured is one of Cocoon's major strengths. However, the current configuration is pretty easy to understand and modify. If the replacement container makes the configuration more complex and less understandable that will really hurt the acceptance of the product.
TBH I always thought that DI moves some complexity from Java code to configuration. But I think that there is an overall gain in simplicity and transparence. If I look at Butterfly's applicationContext.xml it's quite straight forward IMHO.
Guido
I also took a look at Butterfly's applicationContext.xml and did some reading about Spring. I would say that the Spring configuration file looks straight forward from a component developer point of view. But for a Cocoon application developer, possibly without detailed knowledge about the internals of the components and of Cocoon and possibly not even beeing a Java programmer, the Spring configuration file will be much harder to understand and modify.
In the current Cocoon configuration file, you just connect component names to class paths and supply configuration data. In Spring you must as well supply wiring information about how the component is connected to other components thru setters. You need to describe the life cycle, if there are any initialization and destruction methods of the component and the names of them. You need to describe the life style, if it is e.g. a thread safe or poolable component.
IMO, the main problem with the Cocoon configuration file ATM, is its size, not its actual content. From a content POV it gives a rather nice SOC. Migrating to Spring style configuration files would give us a beast that application developers would not dare to go near as it mixes component configuration data with detailed knowledge about the dpeendencies, the life cycle and the life style of the component.
Using Spring style configuration files would make Cocoon rather fragile. I mean, it is a well known problem with property based dependency injection (the favoured style in Spring), that it is hard to know if the component is completely initialized yet. What happens if a user happen to remove a property dependency injection or a destruction attribute from the configuration file, or happens to forget to add them while using a newer version of the component.
---o0o---
I'm not saying that I think the ECM is without problems, but I don't get why it is so important to change the container for _intra-block_ (within block) component handling. From what I can see we mainly change well known problems that we are used to work around with new fresh ones ;), whithout geting that much new functionality.
If it is so important to give users the ability to develop components that can be used from within Cocoon components, but are managed from an external component managers, e.g. Spring or Pico, then we could have a hook in the Cocoon component Manager that calls the external component managers. These component managers could be components living in their on blocks and with own configuration files. AFAIU it would not be that difficult to implement for someone having the itch.
But what would we gain by rewriting all of Cocoon in dependency injection style? And in that case should we use property or constructor injection?
---o0o---
Now what IMO is important is inter-block component handling. That will get us new and much needed functionality in form of "real blocks". And refactoring Cocoon to use Spring will not help us a bit in geting in this direction, AFAIU, as we need class loader isolation for that. And there are no containers featuring class loader isolation out there, except for Pier's one, IIUC.
So IMHO it would be better invested time for us to begin with focusing on the inter-block component handling issues and the new kernel. And base the intra-block component handling on what we learn from that. Who knows, all the current trendy ideas about (light weight) component containers might become obsolete when we get god class loader isolation: see: http://www.betaversion.org/wiki/display/Pier/2004/09/05/Inverting+Inversion+of+Control and http://www.jroller.com/comments/lsd?anchor=java_based_dependency_injection for some herretic ideas ;).
/Daniel
