cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: The real Processor concerns
Date Wed, 12 Oct 2005 08:58:12 GMT
On 11 Oct 2005, at 18:19, Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>> Can you explain how it will work then? Having xconf file sitting  
>> next to sitemap
>> is just syntax sugar, it does not implement any new feature. So  
>> how this feature
>> is getting implementing by taking extra syntax calories?
>>
> Afaik, there are only two use cases for this: auth-fw and global  
> sitemap
> variables. Now, the reason why auth-fw is using this (or the
> authentication manager of auth-fw) is to avoid name clashes. So you  
> can
> have two different sitemaps, let's say on the same level (both mounted
> from the main sitemap), and they can define the same authentication
> handler. Behind the scenes, we only have one authentication manager  
> for
> Cocoon, that evaluates the configuration depending on the sitemap the
> current request is in.
> With 2.2 you can define an authentication manager in each sitemap  
> (or in
> the xconf) and you're done. No magic anymore - this would require a
> slightly changed configuration syntax for the manager.

Sorry if I sound silly, but in the XCONF we can define what  
components we load in the ComponentManager, and are exposed  
throughout the entire Cocoon.

Now, given that 2.2 has a classloader-per-sitemap feature, would that  
mean that the components declared in the sitemap's XCONF are going to  
be loaded by the same classloader?

That would be _FANTASTIC_ for Database mappings (think Hybernate,  
ObjectWeb, et similia).

     Pier


Mime
View raw message