cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Deploying without copying (was: svn commit: r453534)
Date Sun, 08 Oct 2006 20:49:37 GMT
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:


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




and the Spring configurations


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/"/>

In the BlockServlet configuration for e.g. the forms sample the 
blockContextURL property would be set to:


                     --- o0o ---

With such a protocol we would, AFAICS, get rid of the need for copying 


View raw message