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 cob:mycompany.com/webmail/1.3.43)
Why temp directory is not used here? And, where unpacked blocks are stored?
earlier in the RT he said that the location is resolved relative to the webapp dir if relative location is given (WEB-INF/blocks/384938958499 ) but could also be absolute ($TOMCAT_HOME/work/blocks)
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.
Which is unfortunate since that's the one we ship for the demo. So whatever we come up with has to work well for it too out of the box.
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?
Ah, I see your point now - unexploded wars is the issue. Blocks can be wired before building a war, and after webapp deploy if the war is exploded, but if you prefer (or require) the war unexploded you wouldn't be able to deploy new blocks.
So, the WEB-INF/blocks (actually, the location of wiring.xml) must be configurable (which is what I think was proposed anyway) at the webapp level (web.xml?, cocoon.xconf?) from there though, I assume its best to autogenerate some secret key for the actual location (as the \d+ above) to enforce that only the block deploy tool and the block manager know where to locate the actual resources on disk. At least, that's what I assume the purpose of this point in the proposal was. Stefano's off list - anyone know his reasoning on this?
But this brings up another point - what to do if the wiring.xml and others is deleted? Presumably, all blocks are "uninstalled" in this state, but what does this do to persistence requirements.
Also, how to recreate the deploy step efficiently? For example:
You deploy a block with some dependencies and configuration. The block deploy process walks you through setting configs and resolving dependencies. You then have no record of these deployment choices except in wiring.xml which is not meant for human consumption. Perhaps it would be good to record these human-step deployment time configurations in a conf file which could be easily reprocessed to easily re-deploy all blocks to their last configuration.
Alternate versions of this file may be needed as blocks move from dev to staging to live, etc.
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.
I think the unpacked blocks can be anywhere and don't even need to be kept around? The deploy process (the wiring step) will probably have to require specifying the physical location of the cob file. Or maybe this just needs to be a webapp level config (like the unpack/wire destination directory) to specify the block library locations. Am I on the right track here?
Geoff
