[RT] Rethinking the SourceResolver concept

[Carsten Ziegeler <cz...@s-und-n.de>]

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 

Re: [RT] Rethinking the SourceResolver concept

[Christoph Gaffga <cg...@triplemind.com>]

hi,

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

Christoph

"Carsten Ziegeler" <cz...@s-und-n.de> schrieb im Newsbeitrag
news:LKENJPKDAIKAPKHEOCMMEEIFFKAA.cziegeler@s-und-n.de...
> 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
>
>
>

RE: [RT] Rethinking the SourceResolver concept

[Carsten Ziegeler <cz...@s-und-n.de>]

Sylvain Wallez wrote:
> 
> Mmmh... what if a ThreadSafe component declared in cocoon.xconf expects 
> an URI (a string) and then uses the Avalon resolver to get a Source? 
> What base URI will be considered?
> 
The cocoon context directory?

> I'm not sure we can avoid keeping the current base URI in a ThreadLocal.
> 
Yes, me, too. I started this RT to see if someone has a clever idea
to avoid this nasty ThreadLocal thing.

Carsten

Re: [RT] Rethinking the SourceResolver concept

[Sylvain Wallez <sy...@anyware-tech.com>]

Carsten Ziegeler wrote:

>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?
>  
>

Mmmh... what if a ThreadSafe component declared in cocoon.xconf expects 
an URI (a string) and then uses the Avalon resolver to get a Source? 
What base URI will be considered?

I'm not sure we can avoid keeping the current base URI in a ThreadLocal.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com