cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Sun, 17 Oct 2004 15:22:49 GMT
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.


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 


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: 
for some herretic ideas ;).


View raw message