Short background:
In 2.2 blocks can contain configuration files for the components that
they provide (in subdirectories of META-INF) and webapp resources,
sitemap etc (in COB-INF). While building a Cocoon webapp there is a
separate deploy step where the Maven plugin cocoon-deployer-plugin is
used. This plugin scan all the jars that the webapp depends on and look
for certain directories (under META-INF and COB-INF) and copy the
contents of these files to directories in the resulting webapp.
An advantage with this copying process is of course that it is easy to
see what the resulting webapp consists of. But a great disadvantage is
that fast prototyping not works for blocks.
So we discussed how we could get rid of the compile time deployment step
and instead read the needed resources directly from the (possibly
zipped) blocks.
(comments in the end)
Carsten Ziegeler skrev:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Currently the deployer extracts the files from COB-INF and META-INF into
the file system (into the web application). We talked about skipping
this step and adding a mechanism to the core of Cocoon which allows to
access the information from within the jar without extracting it.
This should be doable by using the class loader and some detection
mechanism and avoids the deployer plugin. And more important it means
Seems like cocoon solutions are always a step ahead my comprehension. Is
this really feasible?
Why not?
Giacomo and I talked a little bit about this at the GT and to be honest,
we are not sure if it's 100% feasible, but it should! (I really love
such answers).
We are able to find all jar files containing a COB-INF directory through
the class loader and we should be able to get a stream to this jar.
Then we can just go through the archive, find the files, and register
them somewere.
Actually we are looking for a volunteer to implement this asap :) (If
noone has
done it until the end of October I will herhaps have some time by then).
So, currently Cocoon is setup through Spring by using the namespace
authoring stuff. We currently have a "cocoon:settings" element which
will sets up the settings object of Cocoon and does some minor other stuff.
We could hook up there and:
a) search for all relevant jar files containing a COB-INF directory and
all the other directories we usually extract during deployment. This can
be done using the class loader which returns urls for each jar file.
Which method in the classloader does that? Otherwise we know what
directories to search for jars anyway.
b) Once we have all relevant jar files we can scan them using the usual
zip stuff (we got the url of the jar file in a) ) and get hold of all
relevant files contained in the COB-INF directory (and other locations).
c) We have to extend the various configuration implementations (for
properties, for spring config files and for avalon files) to include the
stuff from b)
I think this is more or less the first step; we talk about some more
details which I can't remember right now. Perhaps Reinhard or Daniel can
fill in here.
Carsten
Using what Carsten describe above we could create a (transversable)
block context protocol:
blockcontext:/<jarname>/<path>
instead of jarname it would be preferable to use the Maven artifact id,
it seem like Maven is storing that within the jar, so maybe we could
extract that. The blockcontext protocol would only need to take care of
the first level in the path hierarchy, for the next level a
(transversable) ZipSource or FileSource is returned.
For fast prototyping the blockcontext Source could also be configured
with a file that connects the block id to the file path of the version
you are working on.
Probably, much of the code from cocoon-deployer-plugin can be reused.
--- o0o ---
With such a block conext protocol we could handle the various
configuration needs.
The cocoon.xconf could include all
blockcontext:/*/META-INF/legacy/xconf/*.xconf
and
blockcontext:/*/META-INF/legacy/sitemap-aditions/*.xconf
and the Spring configurations
blockcontext:/*/META-INF/spring/*.xml
could be included by from the appropriate "Spring in Cocoon" mechanism.
This would probably require that the wildcard mechanism for the the
configuration includes is extended.
The samples would contain things like:
<map:match pattern="*/**">
<map:mount uri-prefix="{1}" src="blockcontext:/{1}/COB-INF/"/>
</map:match>
In the BlockServlet configuration for e.g. the forms sample the
blockContextURL property would be set to:
blockcontext:/cocoon-forms-sample/COB-INF/
--- o0o ---
With such a protocol we would, AFAICS, get rid of the need for copying
files.
/Daniel
