cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
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" <nicolaken@apache.org> wrote:
> 
>>Starting the blocks walk done with microchanges.
> 
> 
> Yeah! :-)
> 
> 
>>microstep 1: loading of components from blocks
>>--------------------------------------------------
>>
>>goal
>>------
>>
>>The goal is that if I specify:
>>
>><map:blocks>
>>  <map:block name="batik"/>
>></map:blocks>
>>
>>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...

Suggestions?

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.

>>benefits
>>----------
>>
>>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 ;-)

>>issues
>>---------
>>
>>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 DefaultTreeBuilder.java, 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message