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 Sun, 14 Sep 2003 16:31:36 GMT
Stefano Mazzocchi wrote:

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

But, it still should be *able* to work as a war, isn't it?

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

That's what I meant, i.e. funny == generated.

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

So the answer will be then: those directories are generated during build 
time. Is there a way to drop in block into expanded war and have block 
deployer pick it up? Deployer will have to then pick up block from some 
directory, generate 123456789 directory, and unpack block there, all in 
runtime, after the build time.

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

We can either provide block deploy directory which will not be dependent 
on container behavior (like we allow specifying work directory in 
web.xml), or provide block temp directory.

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

I'm not trying to.


View raw message