On 30/1/03 9:09, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
