Torsten Curdt wrote:
> 
> > > I encountered the following:
> > >                                    request -> [part]
> > >                                   /
> > > -request-> [ ContentAggregation ] -request -> [part]
> > >                                   \
> > >                                    request -> [part]
> > >                                              does a redirect
> > >                                              via Redirector
> > >                                              inside an action
> > > 
> > > Unfortunately only the aggregated _part_ is redirected.
> > > I would expect a redirect to happen always at root level
> > > of all aggregations.
> > > 
> > > I've looked into the sitemap.xsl and into the ContentAggregator.
> > > But I have found no way of getting to the (Sitemap)Redirector of the
> > > parts. Maybe we could pass the Redirector to the aggregated parts?
> > > Any idea?
> > > 
> > > Then we could easily check each part for "hasRedirected"
> > > inside the sitemap. And everything should work as expected.
> > 
> > Is this really the way one would expect it? The aggregated parts
> > are (often, but not always) available "standalone". If they then
> > do a redirect, you get the redirected response.
> > Now you use aggregation with three parts, one of them is the one
> > described above. As a result you don't get two other parts and
> > the first one, but only the first one. And I think, you
> > wouldn't expect it.
> 
> I have to admit this heavily depends on the use of aggregation.
> I would have expected it because we use it only for local
> aggregation so the subsequent requests of the aggregator are
> not so obvious.
> 
> Your are right this should be configureable per map:part element.
> 
Hm, nice to hear "you are right", but did I say that? I feel making
this configurable is FS.

> Anyway an idea how pass the Redirector?
A new redirector is created for the wrapped environment (AFAIR),
as the wrapped environment wraps the original one, this shouldn't
be a real problem.

> 
> All we have is the Source object... and AFAIU this will lead
> into a completely new request-response cycle, right?!
Right, but a wrapped environment.

Carsten
> --
> Torsten
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to