Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <4555F957.8060600@nada.kth.se>
Date: Sat, 11 Nov 2006 17:24:55 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Run Cocoon without deployer
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It is now possible to use Cocoon without deployer and to use it in 
Eclipse with e.g. the Jetty plugin.

To run Cocoon in Eclipse the shielded mode must, AFAICS, be turned of 
(this is because we need the classpath provided by Eclipse with 
dynamically build class files and resource and not the shielded one that 
point to libraries that the deployer have provided during Maven build 
time). This is done by removing the snippet in the webapp pom that calls 
the Cocoon deployer.

There is a class DeployUtil that search the class loader for all 
instances of COB-INF directories during the startup of Cocoon. The 
DeployUtil create a map that associates block names to the URL of the 
COB-INF directory in the block. For jar: URLs the block name is 
extracted from the Cocoon-Block-Name property in the manifest file. For 
a jar: URL the content of the COB-INF directory is unpacked at the temp 
area of the webapp (allows for running unexpanded wars). And for file: 
URLs the block name is extracted from the path (admittedly a hack).

Then the new BlockContextSource use this association list to get from 
block name to sources.

blockcontext:/ - is resolved to a TraversableSource that make it 
possible to list the blocks (see 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/blocks/sitemap.xmap 
for an example).

blockcontext:/blockname/ - resolves to a file source that contain the 
COB-INF directory of the block.

The block context source is not intended to use in sitemaps within 
blocks as it exposes the block name. Within blocks the context source 
should be used as usual. The block context source is intended for 
setting the context URL in a block servlet configuration and for use in 
a root sitemap for mounting other blocks. The later use should be 
considered as bad practice when the blocks fw stabilizes as block 
internal resources should be considered private ad only be exposed 
through the block protocol.

/Daniel