cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: pipelineComponent scope troubles
Date Wed, 19 Sep 2007 10:57:21 GMT
Giacomo Pati pisze:
> Grzegorz Kossakowski wrote:
>> Giacomo Pati pisze:
>> Hmmm, it should be called more than three times because when executing
>> http://localhost:8080/myBlock1/test the status variable should be put on OM. Is this
a case? You can
> No, status is not put on OM!

That extremely weird!

>> check it by putting breakpoint on org.apache.cocoon.components.flow.FlowHelper.setContextObject().
> Inteersting that now that I have set additional beakpoint I go more calles to the put
> OM ObjId=68 key="java"
> OM ObjId=68 key="cocoon"
> OM ObjId=68 key="Packages"
> OM ObjId=68 key="sitemap"
> OM ObjId=68 key="namespace"

All these puts are expected and look fine.

> But control never reaches FlowHelper.setContextObject()

Any idea what could cause it? I have never changed code executing setContextObject() method
so I
don't think it's me who caused regression. To be honest, I don't think there is any regression
all. Method setContextObject() should be called unconditionally from
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo() and I cannot imagine situation
that you call flowscript function, then sendPage() from flowscript and forwardTo is not called.

Giacomo, I hope that you can figure out what's going on in your environment because I just
lost any
clue and I'm starting to think that your problem has nothing to do with OM or pipelineComponent
scope at all.

>> To give you better idea what we are searching for: I believe that your NPE is caused
by the fact
>> that flowscript puts status variable on one instance of OM and template from myBlock2
uses another
>> instance of OM.
>> You can set breakpoint on org.apache.cocoon.el.impl.jexl.JexlExpression.evaluate()
to find out
>> against which OM instance the expression is evaluated and what it contains.
> The OM passed to the evaluate method is a Proxy. Don't know where to look at. Found a
> with targetBeanName of ""

Ah, you are right, of course. Proxies has caused problems with debugging for me, too. Quite
method to overcome this problem is to just set breakpoint on get() method of ObjectModelImpl
wait for JEXL accessing OM. Then you could figure out which OM instance has been accessed.

However, I don't think that spending time on this check makes sense as long as setContextObject()
method is not called...


Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

View raw message