cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sat, 30 Aug 2003 02:57:23 GMT
Vadim Gritsenko wrote:
> 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?

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?


View raw message