cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Unblocking Blocks - microstep 1
Date Thu, 30 Jan 2003 23:17:27 GMT
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...

> 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?

> 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...

> 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! :-)

    Pier


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


Mime
View raw message