Re: The real Processor concerns

[Pier Fumagalli]

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

have two different sitemaps, let's say on the same level (both mounted
from the main sitemap), and they can define the same authentication

Cocoon, that evaluates the configuration depending on the sitemap the
current request is in.

the xconf) and you're done. No magic anymore - this would require a
slightly changed configuration syntax for the manager.

authentication manager of auth-fw) is to avoid name clashes. So you can handler. Behind the scenes, we only have one authentication manager for With 2.2 you can define an authentication manager in each sitemap (or in

    Pier

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

smime.p7s
Description: S/MIME cryptographic signature