cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Unblocking Blocks - microstep 1
Date Fri, 31 Jan 2003 07:47:42 GMT

Pier Fumagalli wrote:
> On 30/1/03 9:09, "Nicola Ken Barozzi" <> wrote:
>>Starting the blocks walk done with microchanges.
> Yeah! :-)
>>microstep 1: loading of components from blocks
>>The goal is that if I specify:
>>  <map:block name="batik"/>
>>then the sitemap processor will
>>* look in WEB_INF/blocks for the block jars
>>* load the batik-block.jar classes
>>* load the avalon components therein specified in a
>>  cocoon.xconf file in the block jar
>>Note: All other features like versioning, download (of the block and
>>realted jars), etc will be another microstep.
> The only thing I have "against" this is to start thinking about making
> "WEB-INF" an optional feature (all throughout the code)... It should be a
> configurable feature.
> The "web application" concept collides with a "full-server" concept...
> Web-Applications were designed to allow multiple web-applications in the
> same container...
> With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
> let's try to think about a possible non-web-application layout...


The fact is that cocoon.xconf was moved to WEB-INF for security reasons. 
In that servlet environment I would surely move the blocks under 
WEB-INF. IMHO it's simple enough to imagine that in all other 
environments we have a COCOON-INF dir that mimics the WEB_INF one.

>>No more need to recreate the cocoon.jar after the blocks build. This
>>will make cocoon.jar really indipendent from the blocks.
> Shall we think about layering better the build system?

It's not the build system, it's that cocoon.jar now needs that all 
Avalon components be inserted in a property file in cocoon.jar. This is 
why I want to do this microstep ;-)

>>Small step, but already there are issues.
>>1. when we will enable versioning, we can have that a block uses
>>  a version of some libraries, and others another.
>>  This mean that we have to load the blocks with different
>>  classloaders, right?
> Correct... And each classloader should work in the "web-application" mode:
> check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
> big issue though, it could be a problem if we want to start "live reloading"
> of blocks, or pass instances of the same class around between different
> blocks...

yup, let's KISS for now.

>>2. Where does the treeprocessor actually create these components? ;-P
>>  It seems that methods are calling methods that are... you get the
>>  picture... I've got not much time to dwelve into that code, but
>>  I looked at the, but still I'm puzzled.
>>  Can someone please help me and explain how Cocoon uses-handles
>>  the ComponentManager(s), and how the TreeProcessor works?
> On that, I can't help you mate, but once you figure something out, I can
> help you writing some code for it! :-)

Sylvain? (the Source ;-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message