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