cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Gaffga" <>
Subject Re: [RT] Rethinking the SourceResolver concept
Date Thu, 16 Oct 2003 13:38:57 GMT


what a wunderfull day, the idea to make it ThreadSafe sound very attractive
for me.
Perheaps it solves my Problems with the ParallelContentAggregator.


"Carsten Ziegeler" <> schrieb im Newsbeitrag
> The recent discussions about migrating to fortress lead me
> to think about our SourceResolver concept again.
> First the current state:
> - The SourceResolver is an Avalon component that can be
>   looked up everywhere you have a component manager
>   (service manager).
> - The SourceResolver resolves any URI, including the
>   cocoon: protocol.
> - Relative URIs are resolved to the current sitemap.
> - Sitemap components get a cocoon source resolver
>   in the setup() (or act() ...) method.
> - The cocoon source resolver is an interface that
>   is obsolete and is there only for compatibility.
>   It extends the Avalon SourceResolver interface.
> So, a sitemap component always resolves URIs relative
> to it's sitemap.
> But in addition - if you have a usual avalon component,
> e.g. a ThreadSafe one that uses SourceResolver - this
> component resolves URIs relative to the current sitemap
> as well. So the current sitemap acts like a context
> for this component.
> This behaviour led to some more hacky implementations
> to make it work and we had to extend the ECM for this.
> The main problem is to determine the current sitemap.
> We have some thread local variables for this and
> a rather ugly handling for internal requests.
> Now, I think we can make it simpler :)
> a) A sitemap component gets a Cocoon source resolver anyway.
>   We can provide in the setup() method a wrapper for
>   the Avalon SourceResolver that knows it's sitemap. This
>   is simply and doesn't need thread locals etc. anymore.
> b) The only problem lies in all this nice little thread
>   safe components that resolve URIs relative to the
>   current sitemap.
> One solution for b) is to say, relative paths are always
> resolved to the context directory of cocoon than we can
> remove a lot of the hacky things. But I fear this might
> break some things.
> So, what do you think?
> Carsten

View raw message