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 method:
> 
> 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 at
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 targetSource
> with targetBeanName of 
> "scopedTarget.org.apache.cocoon.el.objectmodel.ObjectModel"

Ah, you are right, of course. Proxies has caused problems with debugging for 
me, too. Quite dumb
method to overcome this problem is to just set breakpoint on get() method of 
ObjectModelImpl and
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...

HTH.

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Reply via email to