Sub-sitemaps (was: Changes to the deployer plugin wrt shielded classloading)

[Joerg Heinicke <jo...@gmx.de>]

On 18.11.2006 21:12, Mark Lundquist wrote:
> 
> On Nov 18, 2006, at 5:46 AM, Carsten Ziegeler wrote:
> 
>> 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.
> 
> One aspect of sub-sitemaps, of course, is that they inherit component 
> definitions from upward in the hierarchy... does something like that 
> still work in the new model?

Component inheritance is a standard functionality of Spring's 
ApplicationContext implementations. So this should be no problem at all.

But I wonder if there is a replacement for "fallback to parent sitemap 
if no match was found in sub sitemap".

Jörg

Re: Sub-sitemaps

[Daniel Fagerstrom <da...@nada.kth.se>]

Alexander Klimetschek skrev:
> Joerg Heinicke schrieb:
>> Component inheritance is a standard functionality of Spring's 
>> ApplicationContext implementations. So this should be no problem at all.
>
> Although this is not yet used in any way with the blocks. Two blocks, 
> where one inherits from another, don't know that the other one uses a 
> SitemapServlet, and the only interface between them is the servlet 
> api. Components you define in your sitemap might be known to Spring 
> but its about letting the TreeProcessor know how to resolve component 
> names. So I don't think it is possible at all to integrate that into 
> the blocks fw.
This is by design.

In earlier incarnations of the block architecture, the idea was to have 
component inheritance (and polymorphism) as well as servlet inheritance 
(or rather sitemap inheritance). We had some discussions about what this 
would mean at the list, and the main conclusion is that it gets rather 
complicated. You need to make sure that components always are executed 
in the right context and classloader and this gets really messy when 
combine with polymorphic block protocols that communicate over SAX events :/

And even if we had the energy and ability to solve these problems, I 
that the concept of mixing component reuse and servlet reuse is flawed 
and overly complicated anyway.

IMO, it is much better to consider component management and servlet 
reuse as separate concerns as we do in the current architecture. The 
blocks fw takes care about servlet reuse. For component reuse we have 
Spring. Now the current mechanism for component reuse with Spring in 
Cocoon is rather basic, we could get much further by using OSGi and the 
OSGi-Spring bridge. But we should probably try to release 2.2, before 
starting to work on that ;)

> BTW: What about those sitemap-additions directory?
Didn't we remove them?

/Daniel

Re: Sub-sitemaps

[Alexander Klimetschek <al...@mindquarry.com>]

Joerg Heinicke schrieb:
> Component inheritance is a standard functionality of Spring's 
> ApplicationContext implementations. So this should be no problem at all.

Although this is not yet used in any way with the blocks. Two blocks, 
where one inherits from another, don't know that the other one uses a 
SitemapServlet, and the only interface between them is the servlet api. 
Components you define in your sitemap might be known to Spring but its 
about letting the TreeProcessor know how to resolve component names. So 
I don't think it is possible at all to integrate that into the blocks fw.

BTW: What about those sitemap-additions directory?

> But I wonder if there is a replacement for "fallback to parent sitemap 
> if no match was found in sub sitemap".

With the current blocks-fw implementation we put this matcher at the end 
of all sitemaps that "inherit" from another block, ie. that have a 
"super" block defined in the connections of the BlockServlet bean.

   <match pattern="**">
     <read src="block:super:/{1}" />
   </match>


Alex

-- 
Alexander Klimetschek
http://www.mindquarry.com

Re: Sub-sitemaps

[Alexander Klimetschek <al...@mindquarry.com>]

Joerg Heinicke schrieb:
 > Component inheritance is a standard functionality of Spring's
 > ApplicationContext implementations. So this should be no problem at all.

Although this is not yet used in any way with the blocks. Two blocks, 
where one inherits from another, don't know that the other one uses a 
SitemapServlet, and the only interface between them is the servlet api. 
Components you define in your sitemap might be known to Spring but its 
about letting the TreeProcessor know how to resolve component names. So 
I don't think it is possible at all to integrate that into the blocks fw.

BTW: What about those sitemap-additions directory?

 > But I wonder if there is a replacement for "fallback to parent sitemap
 > if no match was found in sub sitemap".

With the current blocks-fw implementation we put this matcher at the end 
of all sitemaps that "inherit" from another block, ie. that have a 
"super" block defined in the connections of the BlockServlet bean.

   <match pattern="**">
     <read src="block:super:/{1}" />
   </match>


Alex

-- 
Alexander Klimetschek
http://www.mindquarry.com