cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Changes to the deployer plugin wrt shielded classloading
Date Sun, 19 Nov 2006 19:16:36 GMT
Carsten Ziegeler skrev:
> Giacomo Pati wrote:
>> Carsten Ziegeler wrote:
>>> Reinhard Poetz wrote:
>>>> My goal is having a completly self-reloading Cocoon application that also

>>>> includes the block dispatching mechanism and not only at sitemap level. (As
>>>> side note: We shouldn't consider sub-sitemaps as the number one way of 
>>>> modularization in Cocoon anymore).
>>> I think this side note is very important - and this remembers me about
>>> my pending proposal to remove sub sitemaps completly.
>> Hey guys, what does that mean? No more blocks?
> No, no, quiet the opposite. With the new block architecture and the
> dispatching stuff Daniel wrote, you can mount sitemaps in the spring
> context by just defining a sitemap servlet (I don't know the exact term,
> but I hope this gives an impression) which is configured with two
> values, the mount path and the sitemap location.
The dispatcher servlet looks for all Spring managed components that 
implements the Servlet interface and has a mountPath property. The 
dispatcher servlet will dispatch to the mounted servlet which mount path 
is the longest prefix of the path info.

So we could have had a Spring managed sitemap servlet as with a sitemap 
path and a mount path property as you describe above. Such a sitemap 
servlet bean would need to have some extra code for getting the servlet 
context right and geting the initialization order right.

Instead we have a special block servlet that embed an ordinary (non 
managed) servlet as e.g. the sitemap servlet. It also provide some extra 
functionality like the polymorphic block protocol.
>  I'm not sure but I
> think we already have running examples somewhere in our tree.
Sure :)

Take a look at,

for an example that make the forms samples available through the 
dispatcher and block servlet. It should work OOTB in the 
cocoon-dist-samples if you point you browser to 

Some more of the features, like connecting to other blocks servlets with 
DI is demonstrated in the blocks fw samples:

In the cocoon-blocks-fw-demo[1|2] there are examples using the block 
servlet with other servlets than the sitemap servlet.

> By this, you mount new functionality just by adding your components to
> the spring context and that's it. These components (or servlets) are
> called "directly" from the dispatching servlet without going through the
> main sitemap.
> So if you have two sitemaps in your block, one for /myblock and one for
> /myblock/misc, then you add two component definitions to the spring
> context and you don't have to mount the misc sub sitemap in the myblock
> sitemap.

> Removing the need of sub sitemaps would make our architecture and
> implementation *much* cleaner.

But isn't the main problem component configurations in sub sitemaps? 
Wouldn't it be enough (from architectural cleanliness POV) to remove the 
ability to define components in sub sitemaps?


View raw message