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 cob:mycompany.com/webmail/1.3.43)
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.
Vadim
