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
- Run Cocoon without deployer Daniel Fagerstrom
-
