You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2002/07/04 10:14:34 UTC
Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Sylvain,
I'm still trying to fully understand flow and the treeprocessor. I
have the impression, that sending a page does not access internal-only
pipelines. I found that sendPage uses a redirector to actually send
the page in AbstractInterpreter.java. Any idea how this can be marked
as an internal request?
TIA.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> So I think we have a bug here, and I have no obvious solution :
>
> I removed the test for "!this.internal", because internal redirects
> should be considered as internal requests, and so always call
> processInternal().
> --> blank page
>
> This blank page is caused by the pipeline not being processed, so I
> added pp.process(newEnv) after processInternal()
> --> Bang ! _"Unable to get transformer handler for
> stylesheets/site2xhtml.xsl_" (comes from excalibur xslt component)
>
> ??? I'm kinda lost here an have no time now for further investigations.
>
> Carsten, this seems to be related to the changes you made on internal
> processing. Got an idea ?
>
To be honest, I don't the purpose why we have this ForwardRedirector,
so it's a little bit difficult to say, what is right and what is wrong for
me. (It's one of those classes adding more and more complexity).
Anyway, if you call processInternal() the processing pipeline is assembled
correctly but not processed. If you now want to process it, you have to
change the environment (or the context) to the context of the sitemap,
the pipeline was assembled in.
For example, the SitemapSource does it this way:
this.processingPipeline =
this.processor.processInternal(this.environment);
this.pipelineProcessor = this.environment.changeToLastContext();
try {
CocoonComponentManager.enterEnvironment(this.environment,
this.environment.getObjectModel(),
this.pipelineProcessor);
this.processingPipeline.process(this.environment);
} finally {
CocoonComponentManager.leaveEnvironment();
}
Perhaps adding this piece of code helps?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 04.Jul.2002 -- 03:20 PM, Christian Haul wrote:
>
>
>>On 04.Jul.2002 -- 11:50 AM, Sylvain Wallez wrote:
>>
>>
>>>The redirector used (ForwardRedirector) handles the special "cocoon:"
>>>protocol as internal redirects (aka "forward") which should consider the
>>>request as internal.
>>>
>>>However, I noticed Carsten has added a processInternal() method to
>>>Processor and I wonder if there is some side-effects that break internal
>>>pipelines. Can you check if internal pilepelines still work as expected
>>>(using a simple cocoon: source) ? I unfortunately have no time to do it
>>>myself.
>>>
>>>
>
>Mmmh, looking at the stacktrace, ForwardRedirector is in the
>(!this.internal) branch, method cocoonRedirect.
>
> if ( !this.internal ) {
> processingResult = actualProcessor.process(newEnv);
> } else {
> ProcessingPipeline pp = actualProcessor.processInternal(newEnv);
> if (pp != null) pp.release();
> processingResult = pp != null;
> }
>
>Does it make sense to have external redirects handled by the
>cocoonRedirect method at all? It seems that it is invoked only, if the
>URL starts with "cocoon:" and thus should be internal, right?
>
>
Right (see below).
>Regarding the flow: It uses the existing Environment to call
>AbstractInterpreter.forwardTo(), which in turn uses that very
>Environment to obtain a Redirector. Since "internal" is a property of
>that Environment, it cannot be "true" since the original request
>wasn't internal.
>
>Redirecting from a RedirectToURINode works much alike.
>
>So?
>
>
So I think we have a bug here, and I have no obvious solution :
I removed the test for "!this.internal", because internal redirects
should be considered as internal requests, and so always call
processInternal().
--> blank page
This blank page is caused by the pipeline not being processed, so I
added pp.process(newEnv) after processInternal()
--> Bang ! _"Unable to get transformer handler for
stylesheets/site2xhtml.xsl_" (comes from excalibur xslt component)
??? I'm kinda lost here an have no time now for further investigations.
Carsten, this seems to be related to the changes you made on internal
processing. Got an idea ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 04.Jul.2002 -- 03:20 PM, Christian Haul wrote:
> On 04.Jul.2002 -- 11:50 AM, Sylvain Wallez wrote:
> > The redirector used (ForwardRedirector) handles the special "cocoon:"
> > protocol as internal redirects (aka "forward") which should consider the
> > request as internal.
> >
> > However, I noticed Carsten has added a processInternal() method to
> > Processor and I wonder if there is some side-effects that break internal
> > pipelines. Can you check if internal pilepelines still work as expected
> > (using a simple cocoon: source) ? I unfortunately have no time to do it
> > myself.
Mmmh, looking at the stacktrace, ForwardRedirector is in the
(!this.internal) branch, method cocoonRedirect.
if ( !this.internal ) {
processingResult = actualProcessor.process(newEnv);
} else {
ProcessingPipeline pp = actualProcessor.processInternal(newEnv);
if (pp != null) pp.release();
processingResult = pp != null;
}
Does it make sense to have external redirects handled by the
cocoonRedirect method at all? It seems that it is invoked only, if the
URL starts with "cocoon:" and thus should be internal, right?
Regarding the flow: It uses the existing Environment to call
AbstractInterpreter.forwardTo(), which in turn uses that very
Environment to obtain a Redirector. Since "internal" is a property of
that Environment, it cannot be "true" since the original request
wasn't internal.
Redirecting from a RedirectToURINode works much alike.
So?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 04.Jul.2002 -- 11:50 AM, Sylvain Wallez wrote:
> The redirector used (ForwardRedirector) handles the special "cocoon:"
> protocol as internal redirects (aka "forward") which should consider the
> request as internal.
>
> However, I noticed Carsten has added a processInternal() method to
> Processor and I wonder if there is some side-effects that break internal
> pipelines. Can you check if internal pilepelines still work as expected
> (using a simple cocoon: source) ? I unfortunately have no time to do it
> myself.
If I did everything correctly, yes. (Samples are still in disorder, so
I couldn't test with existing sample) In mount/vquadrat/sitemap.xmap:
<map:pipelines>
<map:pipeline internal-only="true">
<map:match pattern="internal/*">
<map:call resource="dynamic-page">
<map:parameter name="target" value="login"/>
</map:call>
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="test">
<map:read src="cocoon://mount/vquadrat/internal/login"/>
</map:match>
</map:pipeline>
DEBUG (2002-07-04) 15:16.59:824 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/DefaultComponentFactory: ComponentFactory creating new instance of org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline.
DEBUG (2002-07-04) 15:16.59:825 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/DefaultComponentFactory: no logger attribute available, using standard logger
DEBUG (2002-07-04) 15:16.59:825 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ResourceLimitingPool: Created a new org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline from the object factory.
DEBUG (2002-07-04) 15:16.59:826 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ResourceLimitingPool: Got a org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline from the pool.
DEBUG (2002-07-04) 15:16.59:826 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ExcaliburComponentSelector: readers: ComponentSelector could not find the component for hint: resource
DEBUG (2002-07-04) 15:16.59:827 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/DefaultComponentFactory: ComponentFactory creating new instance of org.apache.cocoon.reading.ResourceReader.
DEBUG (2002-07-04) 15:16.59:827 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/DefaultComponentFactory: logger attribute is sitemap.reader.resource
DEBUG (2002-07-04) 15:16.59:828 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ResourceLimitingPool: Created a new org.apache.cocoon.reading.ResourceReader from the object factory.
DEBUG (2002-07-04) 15:16.59:828 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ResourceLimitingPool: Got a org.apache.cocoon.reading.ResourceReader from the pool.
INFO (2002-07-04) 15:16.59:831 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/PreparableMatchNode: Matcher 'wildcard' matched prepared pattern 'mount/*/**' at jndi:/localhost/cocoon/sitemap.xmap:461:37
DEBUG (2002-07-04) 15:16.59:832 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/InvokeContext:
Current Sitemap Parameters:
PARAM: '2' VALUE: 'internal/login'
PARAM: '1' VALUE: 'vquadrat'
PARAM: '0' VALUE: 'mount/vquadrat/internal/login'
INFO (2002-07-04) 15:16.59:836 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/PreparableMatchNode: Matcher 'wildcard' matched prepared pattern 'internal/*' at file:/projects/haul/jakarta-tomcat-4.0.4-b3/webapps/cocoon/mount/vquadrat/sitemap.xmap:135:36
But redirecting doesn't:
<map:pipelines>
<map:pipeline internal-only="true">
<map:match pattern="internal/*">
<map:call resource="dynamic-page">
<map:parameter name="target" value="login"/>
</map:call>
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="test">
<map:redirect-to uri="cocoon://mount/vquadrat/internal/login"/>
</map:match>
</map:pipeline>
INFO (2002-07-04) 15:07.42:395 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/RedirectToURINode: Redirecting to 'cocoon://mount/vquadrat/internal/login' at file:/projects/haul/jakarta-tomcat-4.0.4-b3/webapps/cocoon/mount/vquadrat/sitemap.xmap:220:68
INFO (2002-07-04) 15:07.42:395 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/ForwardRedirector: Redirecting to 'cocoon://mount/vquadrat/internal/login'
DEBUG (2002-07-04) 15:07.42:397 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/EnvironmentWrapper: Setting uri (prefix=, uris=mount/vquadrat/internal/login)
DEBUG (2002-07-04) 15:07.42:397 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: Set the URI Prefix (OLD=mount/vquadrat/, NEW=)
INFO (2002-07-04) 15:07.42:398 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/PreparableMatchNode: Matcher 'wildcard' matched prepared pattern 'mount/*/**' at jndi:/localhost/cocoon/sitemap.xmap:461:37
DEBUG (2002-07-04) 15:07.42:398 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/InvokeContext:
Current Sitemap Parameters:
PARAM: '2' VALUE: 'internal/login'
PARAM: '1' VALUE: 'vquadrat'
PARAM: '0' VALUE: 'mount/vquadrat/internal/login'
DEBUG (2002-07-04) 15:07.42:399 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: Changing Cocoon context
DEBUG (2002-07-04) 15:07.42:399 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: from context(file:/projects/haul/jakarta-tomcat-4.0.4-b3/webapps/cocoon/) and prefix()
DEBUG (2002-07-04) 15:07.42:399 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: to context(mount/vquadrat/) and prefix(mount/vquadrat)
DEBUG (2002-07-04) 15:07.42:400 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: at URI mount/vquadrat/internal/login
DEBUG (2002-07-04) 15:07.42:400 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/AbstractEnvironment: New context is file:/projects/haul/jakarta-tomcat-4.0.4-b3/webapps/cocoon/mount/vquadrat/
INFO (2002-07-04) 15:07.42:401 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/PipelineNode: No pipeline matched request: mount/vquadrat/internal/login
WARN (2002-07-04) 15:07.42:401 [sitemap] (/cocoon/mount/vquadrat/test) HttpProcessor[8080][0]/PipelineNode: Resource not found in pipeline at file:/projects/haul/jakarta-tomcat-4.0.4-b3/webapps/cocoon/mount/vquadrat/sitemap.xmap:143:19
With line 143 being the begin of the externally visible pipeline.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>
>
>>-----Original Message-----
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>Sent: Thursday, July 04, 2002 11:50 AM
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: Internal Pipelines (was: [RT] reconsidering pipeline
>>semantics)
>>
>>
>>Christian Haul wrote:
>>
>>
>>
>>>Sylvain,
>>>
>>>I'm still trying to fully understand flow and the treeprocessor. I
>>>have the impression, that sending a page does not access internal-only
>>>pipelines. I found that sendPage uses a redirector to actually send
>>>the page in AbstractInterpreter.java. Any idea how this can be marked
>>>as an internal request?
>>>
>>>
>>>
>>>
>>The redirector used (ForwardRedirector) handles the special "cocoon:"
>>protocol as internal redirects (aka "forward") which should consider the
>>request as internal.
>>
>>However, I noticed Carsten has added a processInternal() method to
>>Processor and I wonder if there is some side-effects that break internal
>>pipelines. Can you check if internal pilepelines still work as expected
>>(using a simple cocoon: source) ? I unfortunately have no time to do it
>>myself.
>>
>>
<snip/>
>>BTW, Carsten, I like very much this new processInternal() as it returns
>>a pipeline object. This should make it very easy to implement pipeline
>>services.
>>
>>
>>
>Thanks.
>Actually this method is not so new at all. In former versions it was
> boolean process(Environment environment, StreamPipeline pipeline,
> EventPipeline eventPipeline)
>
>
Yes, but with your change Processor handles the pipeline creation rather
than accepting an existing one, and I think it's better this way.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Thursday, July 04, 2002 11:50 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Internal Pipelines (was: [RT] reconsidering pipeline
> semantics)
>
>
> Christian Haul wrote:
>
> >Sylvain,
> >
> >I'm still trying to fully understand flow and the treeprocessor. I
> >have the impression, that sending a page does not access internal-only
> >pipelines. I found that sendPage uses a redirector to actually send
> >the page in AbstractInterpreter.java. Any idea how this can be marked
> >as an internal request?
> >
> >
>
> The redirector used (ForwardRedirector) handles the special "cocoon:"
> protocol as internal redirects (aka "forward") which should consider the
> request as internal.
>
> However, I noticed Carsten has added a processInternal() method to
> Processor and I wonder if there is some side-effects that break internal
> pipelines. Can you check if internal pilepelines still work as expected
> (using a simple cocoon: source) ? I unfortunately have no time to do it
> myself.
>
> BTW, Carsten, I like very much this new processInternal() as it returns
> a pipeline object. This should make it very easy to implement pipeline
> services.
>
Thanks.
Actually this method is not so new at all. In former versions it was
boolean process(Environment environment, StreamPipeline pipeline,
EventPipeline eventPipeline)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Internal Pipelines (was: [RT] reconsidering pipeline semantics)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>Sylvain,
>
>I'm still trying to fully understand flow and the treeprocessor. I
>have the impression, that sending a page does not access internal-only
>pipelines. I found that sendPage uses a redirector to actually send
>the page in AbstractInterpreter.java. Any idea how this can be marked
>as an internal request?
>
>
The redirector used (ForwardRedirector) handles the special "cocoon:"
protocol as internal redirects (aka "forward") which should consider the
request as internal.
However, I noticed Carsten has added a processInternal() method to
Processor and I wonder if there is some side-effects that break internal
pipelines. Can you check if internal pilepelines still work as expected
(using a simple cocoon: source) ? I unfortunately have no time to do it
myself.
BTW, Carsten, I like very much this new processInternal() as it returns
a pipeline object. This should make it very easy to implement pipeline
services.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org