cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sat, 13 Sep 2003 10:33:11 GMT

On Friday, Aug 29, 2003, at 18:27 Europe/Rome, Vadim Gritsenko wrote:

>> 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.

yes, but the spec says that temp is not guaranteed to stay. I don't 
want to base such a key functionality on something that is not rock 
solid and temp directories for servlet contexts are designed not to be.

>> 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.

Remember: when cocoon has blocks, you would *not* need to use a war in 
your life anymore for cocoon, only for the naked-cocoon.war file. the 
rest (even cluster replication) will be handled by the block deployer 
tool. [at least, that's my dream]

> 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?

yes, they would appear funny, but keep in mind that those names are 
given by the block deployer. if you wish to have proper names, that 
would be a comman line property away. This, for example, is useful for 
those projects that might wish to still distribute a complete war 
(forrest comes to mind) where the wiring.xml file is generated at build 

>> 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.

that might be a solution, but would force us to consider blocks 
"read-only" because, otherwise, if a block writes something on its 
internal file system, that content is not guaranteed to be persistent.

I agree that you shouldn't store content in your block file system, 
but, hey, the servlet API tried to enforce that with leaving up to the 
containers to unpack wars and failed (even weblogic had to surrender to 
war unpacking for that IO problem).

In theory, it's all nice and good to keep things separate. In practice 
(and I speak out of linotype) having a file system under your feet is a 
great RAD ability and I wouldn't want to see it going away).


View raw message