cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
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
a 
>>>> 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 
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/META-INF/cocoon/spring/cocoon-forms-sample-blockServlet.xml,

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 
http://localhost:8888/blocks-test/cocoon-forms-samples/.

Some more of the features, like connecting to other blocks servlets with 
DI is demonstrated in the blocks fw samples: 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-blocks-fw/cocoon-blocks-fw-sample/src/main/resources/META-INF/cocoon/spring/.

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.
>   
Exactly.

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

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?

/Daniel


Mime
View raw message