cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Fri, 29 Aug 2003 16:27:19 GMT
Geoff Howard wrote:

> Vadim Gritsenko wrote:
>> Stefano Mazzocchi wrote:
>> ...
>>> Ok, great. Does anybody have a problem with the proposed file 
>>> system  layout?
>> AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:
> By default - but as I understood Stefano's last email, it should be 
> possible to override?
>>> the file system layout (relative to the cocoon webapp context) is
>>>    [-] WEB-INF
>>>     L___ [-] blocks
>>>           L___ [-] 384938958499
>>>           |     L___ [-] BLOCK-INF
>>>           |     |     L___ block.xml
>>>           |     L_ (the contents of
>> Why temp directory is not used here? And, where unpacked blocks are 
>> stored?
> Temp dir:
> I've been assuming this file and dir structure is the persistent state 
> for the block manager.

The only servlet engine which wipes out deployment (aka temp, aka 
staging) directory on restart is Jetty. None of the others known to me 
do this.

> If it has deployed the blocks, it records its state in this 
> structure.  At Cocoon restart, this structure (wiring.xml and 
> resulting filesystem tree) is used to initialize the 
> blocks/components/etc. Otherwise the block deployer has to re-deploy 
> everything on restart.  Have I got that right?

Remember, Cocoon is deployed here as a webapp. And webapp can be 
archived into the war file. Now the question: how funny (e.g. 
384938958499) directories get into the war file in the first place?

> Unpacked blocks:
> Good question -- maybe in WEB-INF/blocks ?

I'd suggest to store blocks in WEB-INF/blocks/, and unpack/wire/etc them 
into $temp/blocks, where $temp is temporary directory configured in 
web.xml. WEB-INF/blocks/ can also have blocks.xml to point out to blocks 
which are located outside of the blocks directory, for development needs.


View raw message