cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Demystification of pipelineComponent trouble
Date Wed, 19 Sep 2007 22:22:25 GMT
Hi all,

At the beginning I would like to say that I'm busy with finding new flat (it's a challenge
of
highest order now in Warsaw!; students are even planning to organize some demonstration...
:P) so I
write this e-mail in hurry. But I promise to make it as clear and exact as I can.

My commit in r577222[1] disabled pipelineComponent scope completely because there is no component
using pipelineComponent scope anymore. It means that if anyone of you experience any problem
with
newest trunk IT'S NOT CAUSED BY PIPELINECOMPONENT SCOPE.

I've prepared little sample[2] that aimed to help us figure out what is a real bug that Giacomo
has
been talking about for few days. Unfortunately, I didn't give any words of explanation about
it and
that led to another amount of confusion about whole issue. It's been long time ago since we
lost
concert of what is obvious and what is not when thinking about pipelinecomponent scope trouble.

Here goes the explanation:
I wanted all of you to just test http://localhost:8888/myBlock1/test and nothing else. This
url
should produce nice XML and no exceptions should be thrown.
Giacomo asked Felix to test http://localhost:8888/myBlock2/screens/obtain-data and, unsurprisingly,
he got the exception the same as Giacomo got. Actually, it's also the same as I got when accessing
that url ;-)

Why this fail? Let's analyse the pipeline processing obtain-data:
      <map:match pattern="screens/obtain-data">
        <map:generate src="screens/obtain-data.xml"/>
        <map:transform type="jx"/>
        <map:serialize type="xml"/>
      </map:match>

Here goes obtain-data.xml:
<?xml version="1.0" encoding="UTF-8"?>
<test>
  <size>${status.myTasks.size()}</size>
</test>

As you see, this pipeline just process simple JX template that tries to access one variable
(status.myTasks) and fails at this point. It must fail (by throwing NPE) because there is
no
status.myTasks variable in OM! It's the flowscript code from myBlock1 that is responsible
for
setting it and that's why the only valid way to test my sample:
calling http://localhost:8888/myBlock1/test

Could anyone try it with newest trunk and report if it works?

Even though we have not much moved forward with helping Giacomo sort out his problem I would
like to
admit that I learned a lot how precision is important and how much there is to learn about
proper
communication.

PS. You can see that's not the semi-formal analysis Daniel asked me to give but since
pipelineComponent scope is switched off and we are just about releasing new candidate I thought
writing such e-mail is much important.

[1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/25164
[2] http://people.apache.org/~gkossakowski/c2.2-test.tar.gz

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

Mime
View raw message