You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gk...@apache.org> on 2007/09/10 15:11:54 UTC
pipelineComponent scope troubles (was: Re: Refactoring cocoon-thread)
Giacomo Pati pisze:
>
>
> Grzegorz Kossakowski wrote:
>> Giacomo Pati pisze:
>
>> Are you sure you are running latest trunk?
>
> Hmm.. if a 'svn up' isn't enough to get there, tell me how else.
It's enough, sorry for asking dumb questions.
>> You are having a trouble with the code handling
>> pipelineComponent scope and proper initialization of parent Object Model within it.
>
> Tell me news, dear ;-)
Ok, next time I'm going to be more concise and see above. ;-)
>> I explained the
>> problem that this code solves here[1] and idea behind the code here[2]. As Joerg pointed out[3] this
>> code is rather first sketch and must be rewritten to follow best practices in Spring.
>
> Ok, so is it working or not!
As far as I managed to test, it works.
>
> If it cannot happen, why is it happening to me, than?
Let me guess: bug? :)
See below
> <map:match pattern="*/**">
> <map:mount uri-prefix="{1}" src="blockcontext:/{1}/" />
> </map:match>
>
> Is that causing the troubles?
Yes, I'm almost sure that's the reason why pipelineComponent scope is freaking.
Both cocoon: source and <map:mount/> are considered old-fashioned if we have Servlet Service
Framework that does the same in more clear and powerful way. Independently from our preferences, we
need to support both cocoon: and <map:mount/>, obviously. In order to provide back-compatibility we
need to implement sitemap scope (see COCOON-2099).
If you are going to make effort of implementing this scope, don't forget to assign that issue to
yourself. I unassigned it because my list of assigned issues is already long and I'm overwhelmed
with other affairs.
If you want to make a quick test if it's the only problem with current trunk and work-around NPE
mentioned by you just change scope of ObjectModel from "pipelineComponent" to "call" in this
file[1]. Be warned that it's only a quick work-around and implementation of sitemap scope is the
only reliable solution.
HTH.
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>> I'm almost sure that if you change scope of OM to request it's going to work. Just make sure that
>> old junk is not sitting somewhere in the classpath. If it's not the case, I must get working example
>> of problematic behaviour in order to help anyhow.
>
> Giacomo, any news on this? I'm very interested in sorting this out if your problems persists.
Sorry, didn't had time to checkout a virgin 2.2, build allblocks, build my app etc., etc.
Will do tomorrow.
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG7sssLNdJvZjjVZARAoImAJoCt6A/cEvdFTqSVd1E+dg4jdzkNgCfZ3D/
RYB50W0omrs5MaESuoWtpfo=
=YJ1+
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
>
> I'm almost sure that if you change scope of OM to request it's going to work. Just make sure that
> old junk is not sitting somewhere in the classpath. If it's not the case, I must get working example
> of problematic behaviour in order to help anyhow.
Giacomo, any news on this? I'm very interested in sorting this out if your problems persists.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Grzegorz Kossakowski wrote:
>>> Giacomo Pati pisze:
>>> Giacomo, this issue caused frustration that affected all of us but I would like to ask you about a
>>> little more. Could you start my sample in a debugger and set breakpoint on put() method of
>>> ObjectModelImpl? Then could you analyse all calls to that method and figure out if they are
>>> operating on the same ObjectModelImpl class instance?
>>> You should debug with OM's scope set to request. The expected result is that during whole request
>>> processing (including making a servlet call) every method call should be on the same instance of OM.
>> Every method call _is_ on the same instance. The put method gets called 3 times with:
>>
>> 1. ObjId=68 key="java"
>> 2. ObjId=68 key="cocoon"
>> 3. ObjId=68 key="Packages"
>
> 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!
> 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"
But control never reaches FlowHelper.setContextObject()
> 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"
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8PgbLNdJvZjjVZARAmd+AKCYiHa1IctFXyB73v49GxUuasPeDQCfdpyP
tBaVZ9JrD2z+fkxoq0YbH1A=
=DIWG
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
>
> Grzegorz Kossakowski wrote:
>> Giacomo Pati pisze:
>> Giacomo, this issue caused frustration that affected all of us but I would like to ask you about a
>> little more. Could you start my sample in a debugger and set breakpoint on put() method of
>> ObjectModelImpl? Then could you analyse all calls to that method and figure out if they are
>> operating on the same ObjectModelImpl class instance?
>> You should debug with OM's scope set to request. The expected result is that during whole request
>> processing (including making a servlet call) every method call should be on the same instance of OM.
>
> Every method call _is_ on the same instance. The put method gets called 3 times with:
>
> 1. ObjId=68 key="java"
> 2. ObjId=68 key="cocoon"
> 3. ObjId=68 key="Packages"
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
check it by putting breakpoint on org.apache.cocoon.components.flow.FlowHelper.setContextObject().
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.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Giacomo Pati wrote:
>>> I'm going to throw away my .m2, recompile it, and check your sample again. I just want to be sure,
>>> but this is going a little while.
>> Ok, I've done as written above but have the same results. No matter what settings I have in
>> core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
>> I always get the same stack traces:
>>
>> http://people.apache.org/~giacomo/GrekSample-pipelineComponent.log
>> http://people.apache.org/~giacomo/GrekSample-request.log
>>
>> Sorry, I get something different that you, so I'm stuck and cannot upgrade to it with my projects!
>
> Giacomo, this issue caused frustration that affected all of us but I would like to ask you about a
> little more. Could you start my sample in a debugger and set breakpoint on put() method of
> ObjectModelImpl? Then could you analyse all calls to that method and figure out if they are
> operating on the same ObjectModelImpl class instance?
> You should debug with OM's scope set to request. The expected result is that during whole request
> processing (including making a servlet call) every method call should be on the same instance of OM.
Every method call _is_ on the same instance. The put method gets called 3 times with:
1. ObjId=68 key="java"
2. ObjId=68 key="cocoon"
3. ObjId=68 key="Packages"
HTH
> If it's not the case just try to find out what and when creates new instances of OM. Since my sample
> works fine for Reinhard it must be something really unusual with your env.
>
> I'm going to describe in detail pipelineComponent scope as Daniel asked me for so it may be easier
> for you to track the code you are (hopefully) going to debug.
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8O8MLNdJvZjjVZARAkv1AJ9AK5CQ6YcCG7VCSN1iJ1N/m/qPQACfRUo2
TEYE/SBuw1H1Vviwra35BPg=
=tZGC
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
>
> Giacomo Pati wrote:
>> I'm going to throw away my .m2, recompile it, and check your sample again. I just want to be sure,
>> but this is going a little while.
>
> Ok, I've done as written above but have the same results. No matter what settings I have in
> core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
> I always get the same stack traces:
>
> http://people.apache.org/~giacomo/GrekSample-pipelineComponent.log
> http://people.apache.org/~giacomo/GrekSample-request.log
>
> Sorry, I get something different that you, so I'm stuck and cannot upgrade to it with my projects!
Giacomo, this issue caused frustration that affected all of us but I would like to ask you about a
little more. Could you start my sample in a debugger and set breakpoint on put() method of
ObjectModelImpl? Then could you analyse all calls to that method and figure out if they are
operating on the same ObjectModelImpl class instance?
You should debug with OM's scope set to request. The expected result is that during whole request
processing (including making a servlet call) every method call should be on the same instance of OM.
If it's not the case just try to find out what and when creates new instances of OM. Since my sample
works fine for Reinhard it must be something really unusual with your env.
I'm going to describe in detail pipelineComponent scope as Daniel asked me for so it may be easier
for you to track the code you are (hopefully) going to debug.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
>
> I'm going to throw away my .m2, recompile it, and check your sample again. I just want to be sure,
> but this is going a little while.
Ok, I've done as written above but have the same results. No matter what settings I have in
core/cocoon-pipeline/cocoon-pipeline-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
I always get the same stack traces:
http://people.apache.org/~giacomo/GrekSample-pipelineComponent.log
http://people.apache.org/~giacomo/GrekSample-request.log
Sorry, I get something different that you, so I'm stuck and cannot upgrade to it with my projects!
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8CTOLNdJvZjjVZARAg76AJ9gP29nOcCEx5FND5V6Vqa2/D52FQCfffSX
svA0e7BfJ4BRj5ozRTrhdhg=
=i6f3
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Giacomo Pati wrote:
>>> Grzegorz Kossakowski wrote:
>>>
>>> To be honest, I get almost the same stack trace with your little sample.
>
> Just to make sure: you have configured OM to be in request scope instead of pipelineComponent scope?
Yes.
> I ask because my sample works (for me) following way:
> 1. If I have OM configured to be in pipelineComponent scope NPE is thrown and I get similar stack
> trace to yours.
You can see the log at http://people.apache.org/~giacomo/GrekSample-pipelineComponent.log
> 2. BUT if I switch to request scope everything works fine and assuming there is no other bug in my
> code it's all fine and expected.
Nope. Here not
You can see the log at http://people.apache.org/~giacomo/GrekSample-request.log
I've also verified, that the correct jar is take from my m2 repo in each case (compared the size
with that one in the corresponding target directory).
Interestingly, I've also done a diff of these two log files and guess what, they are exactly the
same ?!?!?!
I've also checked my cocoon trunk via 'svn st' but the only difference is the ObjectModel.xml.
I'm going to throw away my .m2, recompile it, and check your sample again. I just want to be sure,
but this is going a little while.
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG8BkXLNdJvZjjVZARAmckAJ9bLkhGWYZAkbxrobv5ad161uRjlACfVqrh
Ckjp9RjBlHwbeWA8N4qNk1I=
=iJUD
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> ok, request scope works for me.
Good to know. It's a little progress. What about you, Giacomo?
> sorry, I've read your mail but misunderstood it.
No problem. It's good that we are moving forward, now.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Giacomo Pati wrote:
>>> Grzegorz Kossakowski wrote:
>>>
>>> To be honest, I get almost the same stack trace with your little sample.
>
> Just to make sure: you have configured OM to be in request scope instead of
> pipelineComponent scope? I ask because my sample works (for me) following
> way: 1. If I have OM configured to be in pipelineComponent scope NPE is
> thrown and I get similar stack trace to yours. 2. BUT if I switch to request
> scope everything works fine and assuming there is no other bug in my code
> it's all fine and expected.
ok, request scope works for me.
>> Grek, your sample doesn't run for me either. From a quick glance I'd say
>> that it's the same stacktrace as Giacomo posted.
>
> See above.
>
>> I also think that it's the same problem why the samples from trunk do not
>> run here.
>
> I don't think so...
>
> I would be grateful if you all could take a little effort and understand how
> things work (by reading my e-mails carefully) so you would be better at
> reporting and less blaming at the same time.
sorry, I've read your mail but misunderstood it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Giacomo Pati wrote:
>> Grzegorz Kossakowski wrote:
>>
>> To be honest, I get almost the same stack trace with your little sample.
Just to make sure: you have configured OM to be in request scope instead of pipelineComponent scope?
I ask because my sample works (for me) following way:
1. If I have OM configured to be in pipelineComponent scope NPE is thrown and I get similar stack
trace to yours.
2. BUT if I switch to request scope everything works fine and assuming there is no other bug in my
code it's all fine and expected.
> Grek, your sample doesn't run for me either. From a quick glance I'd say
> that it's the same stacktrace as Giacomo posted.
See above.
> I also think that it's the same problem why the samples from trunk do
> not run here.
I don't think so...
I would be grateful if you all could take a little effort and understand how things work (by reading
my e-mails carefully) so you would be better at reporting and less blaming at the same time.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> Grzegorz Kossakowski wrote:
>> Giacomo Pati pisze:
>>> Yes, clean my M2 repo.
>>>
>>>> of problematic behaviour in order to help anyhow.
>>> Still have the problems. With scpre="request" I got the stack trace after the first request found
>>> at http://people.apache.org/~giacomo/request-log4j-2.log
>> I fear that we got stuck. Without working code exhibiting your problem I cannot help any further.
>>
>> I made an attempt to recreate your setup and even reproduce the same problem. I attach this sample
>> application to my e-mail. If you made it failing with OM/@scope="request" I'm happy to play with it
>> little more and kill this nasty bug.
>
> To be honest, I get almost the same stack trace with your little sample.
Grek, your sample doesn't run for me either. From a quick glance I'd say that
it's the same stacktrace as Giacomo posted.
I also think that it's the same problem why the samples from trunk do not run here.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>> Yes, clean my M2 repo.
>>
>>> of problematic behaviour in order to help anyhow.
>> Still have the problems. With scpre="request" I got the stack trace after the first request found
>> at http://people.apache.org/~giacomo/request-log4j-2.log
>
> I fear that we got stuck. Without working code exhibiting your problem I cannot help any further.
>
> I made an attempt to recreate your setup and even reproduce the same problem. I attach this sample
> application to my e-mail. If you made it failing with OM/@scope="request" I'm happy to play with it
> little more and kill this nasty bug.
To be honest, I get almost the same stack trace with your little sample.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG7+c0LNdJvZjjVZARAne6AJ4rEW582EjNSRZrdyC+y9HF++4fxgCgs9Yk
7saQP61qZOx7CCRfJ0r2qBc=
=58f6
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
...
>>> Sorry for little offending words but I'm really tired repeating the
>>> same thing around ten times and
>>> being blamed in the end.
>> In general, if one repeat the same thing ten times whithout anyone
>> understanding it, it just might be relevant feedback on ones
>> presentation style ;)
>
> I would be grateful for any criticism and I am aware that my English skills are not of highest
> order.
I have no problems following your English, so its good enogh for me. I
leave the finer details to the native speakers ;)
> So here goes my humble request:
> If you really have hard times understanding me or I'm just boring for too long don't hesitate to
> just point it. I've already learned a lot from this community and polishing communication skills
> would be great addition. :-)
I'll point it out next time I have some specific suggestion. A more
general suggestion is that when you use referential words like "it" or
"this" I often have to make an effort to find out what you are refering
to which sometimes makes it time consuming to understand what you mean.
If you would be more generous in repeating what object you refer to it
would help me.
Concrete examples helps tremendesly for understanding things. But I'm of
course aware about that they take time to construct and describe and
that it is an aera where most of us could improve ;)
>>> I hope that we can summarize current situation, cut new release
>>> candidate of C2.2 and return back to
>>> whiteboard for a while.
>> Anyway, my propsal that you give an explicit description about the
>> assumed state before and after the context change, is a serious
>> proposal. If you have described it, please give me a link. Otherwise it
>> would be really helpfull if you write it down.
>
> Ok, I'll write separate e-mail explaining how everything is supposed to work.
Great!
/Daniel
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> You cannot possibly expect that the whole community would have the time
> or interest to follow your sometimes painful way though all the
> complicated details of Cocoon internals.
I agree with that and that was my motivation for writing that e-mail: to summarize many issues that
cover lots of areas in one place and give necessary pointers. But let's give it a rest...
>> Sorry for little offending words but I'm really tired repeating the
>> same thing around ten times and
>> being blamed in the end.
>
> In general, if one repeat the same thing ten times whithout anyone
> understanding it, it just might be relevant feedback on ones
> presentation style ;)
I would be grateful for any criticism and I am aware that my English skills are not of highest
order. So here goes my humble request:
If you really have hard times understanding me or I'm just boring for too long don't hesitate to
just point it. I've already learned a lot from this community and polishing communication skills
would be great addition. :-)
>> I hope that we can summarize current situation, cut new release
>> candidate of C2.2 and return back to
>> whiteboard for a while.
>
> Anyway, my propsal that you give an explicit description about the
> assumed state before and after the context change, is a serious
> proposal. If you have described it, please give me a link. Otherwise it
> would be really helpfull if you write it down.
Ok, I'll write separate e-mail explaining how everything is supposed to work.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Giacomo Pati pisze:
...
>> So, getting to the point, what I propose is that you describe in a
>> semiformal way what is supposed to be true about stack and other state
>> before enetering the scope, during the scope and when leaving it. This
>> will be helpful both for you and for the rest of us for being able to
>> see if your approach and code is correct.
>
> Yep, I agree. I've done such analysis to some extent when proposing[1] pipelineComponent scope and
> then discussing details in that thread.
I reread the thread and the only message I found that go into more
details about the implementation is
http://article.gmane.org/gmane.text.xml.cocoon.devel/74714. But you
while you discuss some details about how you don't describe what. So I
would like to have an explicit description of the state before and after
the context change.
>> Now, the above can seem like a rather indirect and inneficient way to
>> find the problem behind the bug that Giacomo found. For code in general
>> it isn't the way to go. But for things like building execution machines
>> for languages (as in the current case) my experience strongly suggest
>> that what I propose is the most efficient way to go.
...
> I put really a lot of effort in order to clarify things and provide overall picture of current state
> of our code in my RT e-mail. What I found disheartening was the fact that no Cocoon developer
> bothered to say at last: "Grzegorz, I don't understand any paragraph of your e-mail, you just
> screwed it up". Then I wouldn't be surprised by people surprised by current implementation.
You cannot possibly expect that the whole community would have the time
or interest to follow your sometimes painful way though all the
complicated details of Cocoon internals.
> Sorry for little offending words but I'm really tired repeating the same thing around ten times and
> being blamed in the end.
In general, if one repeat the same thing ten times whithout anyone
understanding it, it just might be relevant feedback on ones
presentation style ;)
> I hope that we can summarize current situation, cut new release candidate of C2.2 and return back to
> whiteboard for a while.
Anyway, my propsal that you give an explicit description about the
assumed state before and after the context change, is a serious
proposal. If you have described it, please give me a link. Otherwise it
would be really helpfull if you write it down.
/Daniel
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Giacomo Pati pisze:
>>
>>> Yes, clean my M2 repo.
>>>
>>>
>>>> of problematic behaviour in order to help anyhow.
>>>>
>>> Still have the problems. With scpre="request" I got the stack trace
>>> after the first request found
>>> at http://people.apache.org/~giacomo/request-log4j-2.log
>>>
>>
>> I fear that we got stuck. Without working code exhibiting your problem
>> I cannot help any further.
>>
> Don't know if you are going to like it ;) Have you studied how you prove
> algorithm correctness yet?
Yes I have. We have quite stuffed programme at Warsaw University.
> If not, the idea is that you give a formal
> definition of the precondition of the algorithm, what is true about
> input data before you run the algorithm. You also describe the post
> condition, what is supposed to be true about the output of the
> algorithm. The you use your creativity and state an invariant, something
> that will be true about the state variables of the algorthm at all time
> through the execution. Then the remaining and rather mechanical step is
> to show that the precondition and the operations leads to the invariant,
> that loops or recursions preserve the invariant and that the invariant
> together with the stop condition leads to the postcondition.
>
> OK, doing the above in a formal way, would require an completely
> unrealistic amount of work for the object model and the pipeline scope.
> But following the general scheme in an unformal way is often quite
> helpful for understanding and describing complex algorthms.
>
> So, getting to the point, what I propose is that you describe in a
> semiformal way what is supposed to be true about stack and other state
> before enetering the scope, during the scope and when leaving it. This
> will be helpful both for you and for the rest of us for being able to
> see if your approach and code is correct.
Yep, I agree. I've done such analysis to some extent when proposing[1] pipelineComponent scope and
then discussing details in that thread.
> Now, the above can seem like a rather indirect and inneficient way to
> find the problem behind the bug that Giacomo found. For code in general
> it isn't the way to go. But for things like building execution machines
> for languages (as in the current case) my experience strongly suggest
> that what I propose is the most efficient way to go.
What I found up to date with Giacomo's trouble is that most of Cocooners seems to consider servlet:
as easy replacement for cocoon: source. From what I see most people think that they can just setup
blocks and use find&replace in their IDE and everything will be working using SSF. The point is
that's not true.
At this point, servlet source does *NOT* forward environment (including OM) to called servlet. I
repeat this: it does NOT forward anything, servlet requests are virgin ones. Of course, when using
old code that does not take advantage of Spring scopes one will be able to reuse anything she likes
between servlets but OM is a new code that *DOES* take advantage of Spring scopes.
I put really a lot of effort in order to clarify things and provide overall picture of current state
of our code in my RT e-mail. What I found disheartening was the fact that no Cocoon developer
bothered to say at last: "Grzegorz, I don't understand any paragraph of your e-mail, you just
screwed it up". Then I wouldn't be surprised by people surprised by current implementation.
Sorry for little offending words but I'm really tired repeating the same thing around ten times and
being blamed in the end.
I hope that we can summarize current situation, cut new release candidate of C2.2 and return back to
whiteboard for a while.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74560
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Giacomo Pati pisze:
>
>> Yes, clean my M2 repo.
>>
>>
>>> of problematic behaviour in order to help anyhow.
>>>
>> Still have the problems. With scpre="request" I got the stack trace after the first request found
>> at http://people.apache.org/~giacomo/request-log4j-2.log
>>
>
> I fear that we got stuck. Without working code exhibiting your problem I cannot help any further.
>
Don't know if you are going to like it ;) Have you studied how you prove
algorithm correctness yet? If not, the idea is that you give a formal
definition of the precondition of the algorithm, what is true about
input data before you run the algorithm. You also describe the post
condition, what is supposed to be true about the output of the
algorithm. The you use your creativity and state an invariant, something
that will be true about the state variables of the algorthm at all time
through the execution. Then the remaining and rather mechanical step is
to show that the precondition and the operations leads to the invariant,
that loops or recursions preserve the invariant and that the invariant
together with the stop condition leads to the postcondition.
OK, doing the above in a formal way, would require an completely
unrealistic amount of work for the object model and the pipeline scope.
But following the general scheme in an unformal way is often quite
helpful for understanding and describing complex algorthms.
So, getting to the point, what I propose is that you describe in a
semiformal way what is supposed to be true about stack and other state
before enetering the scope, during the scope and when leaving it. This
will be helpful both for you and for the rest of us for being able to
see if your approach and code is correct.
Now, the above can seem like a rather indirect and inneficient way to
find the problem behind the bug that Giacomo found. For code in general
it isn't the way to go. But for things like building execution machines
for languages (as in the current case) my experience strongly suggest
that what I propose is the most efficient way to go.
/Daniel
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
> Yes, clean my M2 repo.
>
>> of problematic behaviour in order to help anyhow.
>
> Still have the problems. With scpre="request" I got the stack trace after the first request found
> at http://people.apache.org/~giacomo/request-log4j-2.log
I fear that we got stuck. Without working code exhibiting your problem I cannot help any further.
I made an attempt to recreate your setup and even reproduce the same problem. I attach this sample
application to my e-mail. If you made it failing with OM/@scope="request" I'm happy to play with it
little more and kill this nasty bug.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>> Giacomo Pati pisze:
>>> You'll find the log for request scoped at http://people.apache.org/~giacomo/request-log4j.log
>>> and singleton scoped at http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
>>> doesn't even start the app.
>> Ok, that is all weird and definitively worth looking at. I'm just about creating similar setup to
>> yours and debug a little.
>
> Giacomo, I have some news. I managed to reproduce your problem by creating two blocks and setup them
> as we discussed earlier. It turned out that I was right suspecting it's a problem with a scope but
> with pipelineComponent only call scope. Your problem is as simple as the fact that flowscript put on
> different instance of OM than jx was pulling from.
>
> It is caused by the fact that call scope (and pipelineComponent scope is meant to be "inside" call
> scope) is empty whenever new internal call to another servlet is made. That means, when Cocoon makes
> servlet:bfabric-core:/screen/{1} request OM containing status variable is not available in a
> bfabric-core. It means that call scope and whole SSF is designed to NOT share any environmental
> data, at least at this stage. I discussed it in detail in this e-mail[1] but I got only one
> response, sadly enough.
>
> I'm almost sure that if you change scope of OM to request it's going to work. Just make sure that
> old junk is not sitting somewhere in the classpath. If it's not the case, I must get working example
Yes, clean my M2 repo.
> of problematic behaviour in order to help anyhow.
Still have the problems. With scpre="request" I got the stack trace after the first request found
at http://people.apache.org/~giacomo/request-log4j-2.log
>
> [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74571
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG78mFLNdJvZjjVZARAqXXAKDUzMX90SKABEfwaXJeFqFAccAVOACg4Cwi
YUeDVY3wny7hPFhkrqeR2a4=
=D1QA
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
> Giacomo Pati pisze:
>> You'll find the log for request scoped at http://people.apache.org/~giacomo/request-log4j.log
>> and singleton scoped at http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
>> doesn't even start the app.
>
> Ok, that is all weird and definitively worth looking at. I'm just about creating similar setup to
> yours and debug a little.
Giacomo, I have some news. I managed to reproduce your problem by creating two blocks and setup them
as we discussed earlier. It turned out that I was right suspecting it's a problem with a scope but
with pipelineComponent only call scope. Your problem is as simple as the fact that flowscript put on
different instance of OM than jx was pulling from.
It is caused by the fact that call scope (and pipelineComponent scope is meant to be "inside" call
scope) is empty whenever new internal call to another servlet is made. That means, when Cocoon makes
servlet:bfabric-core:/screen/{1} request OM containing status variable is not available in a
bfabric-core. It means that call scope and whole SSF is designed to NOT share any environmental
data, at least at this stage. I discussed it in detail in this e-mail[1] but I got only one
response, sadly enough.
I'm almost sure that if you change scope of OM to request it's going to work. Just make sure that
old junk is not sitting somewhere in the classpath. If it's not the case, I must get working example
of problematic behaviour in order to help anyhow.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74571
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
> You'll find the log for request scoped at http://people.apache.org/~giacomo/request-log4j.log
> and singleton scoped at http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
> doesn't even start the app.
Ok, that is all weird and definitively worth looking at. I'm just about creating similar setup to
yours and debug a little.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Ok, so this is the snippet where it is used:
>>
>> <a href="view-my-tasks" id="view-my-tasks">
>> ${status.myTasks.size()}
>> </a>
>>
>> As it is part of the content surrounding of that page it was included by a XSLT via:
>>
>> <ci:include element="status" src="cocoon:/user-status" />
>>
>> which was processed by a
>>
>> <map:match pattern="user-*">
>> <map:read src="screens/user-{1}.xml" />
>> </map:match>
>>
>> and initially called by a flowscript that sets the status variable up as a native Javascript Hash
>>
>> var status = { myTasks: taskManager.getTasks() };
>>
>> whereas the taskManager.getTasks() returns a List
>>
>> So the general process is that a flowscripts calls the pipeline descibed in my earlier mail with a
>> hash of informations where that pipeline expands the initial xml into cinclude which gets included
>> to the final page.
>
> I want to reproduce your setup so I will want to make sure that I understand your flow in pipelines:
>
> flowscript_function (sets status.myTasks)
> * <map:match pattern="screen/**">
> o <map:generate src="servlet:bfabric-core:/screen/{1}" />
> # generator
> # xslt (creates <ci:include element="status" src="cocoon:/user-status" />)
> # cinclude
> # jx transformer <- here status.myTasks is used
> # serialize
> o [...]
Yes, this is more or less about it.
> Apart from my guesses above I would like to ask you for one more thing, could you set scope of OM to
> request (I hope we support standard Spring scopes) and singleton if request does not work. Be
> warned, that setting it to singleton is just for testing; it will screw up your app as soon as
> second request is processed.
You'll find the log for request scoped at http://people.apache.org/~giacomo/request-log4j.log
and singleton scoped at http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
doesn't even start the app.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG6pyeLNdJvZjjVZARApvBAKCFU52L8V2tCB+1gerpR33fjJBqRgCeMG4C
S5nZiIbmx4d2NN/kqT14m/0=
=33/T
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
>
> Ok, so this is the snippet where it is used:
>
> <a href="view-my-tasks" id="view-my-tasks">
> ${status.myTasks.size()}
> </a>
>
> As it is part of the content surrounding of that page it was included by a XSLT via:
>
> <ci:include element="status" src="cocoon:/user-status" />
>
> which was processed by a
>
> <map:match pattern="user-*">
> <map:read src="screens/user-{1}.xml" />
> </map:match>
>
> and initially called by a flowscript that sets the status variable up as a native Javascript Hash
>
> var status = { myTasks: taskManager.getTasks() };
>
> whereas the taskManager.getTasks() returns a List
>
> So the general process is that a flowscripts calls the pipeline descibed in my earlier mail with a
> hash of informations where that pipeline expands the initial xml into cinclude which gets included
> to the final page.
I want to reproduce your setup so I will want to make sure that I understand your flow in pipelines:
flowscript_function (sets status.myTasks)
* <map:match pattern="screen/**">
o <map:generate src="servlet:bfabric-core:/screen/{1}" />
# generator
# xslt (creates <ci:include element="status" src="cocoon:/user-status" />)
# cinclude
# jx transformer <- here status.myTasks is used
# serialize
o [...]
Apart from my guesses above I would like to ask you for one more thing, could you set scope of OM to
request (I hope we support standard Spring scopes) and singleton if request does not work. Be
warned, that setting it to singleton is just for testing; it will screw up your app as soon as
second request is processed.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>> Here it is :-)
>>
>
> <snip/>
>
> I agree, it's *ugly* :-)
:-)
<snip/>
> I guess that you came across nasty bug in JEXL that tries to evaluate built-in functions on null values
> and informs about it in very bad way.
>
> The question is: where and how status.myTasks is supposed to be set? (see below, also)
See below
> <snip/>
>> <map:match pattern="screen/**">
>> <map:select type="resource-exists">
>> <map:when test="{1}.xml">
>> <map:generate src="{1}.xml" label="content" />
>> </map:when>
>> <map:otherwise>
>> <map:generate src="servlet:bfabric-core:/screen/{1}" />
>
> Let me guess: status.myTasks is called in that pipeline, right?
Yes, at the end yes called in a pipeline (as everything in Cocoon).
> <snip/>
>
>>> Not that much, unfortunately because it only shows that something is broken in pipelineComponent
>>> scope code so no news here. I suggest to do three things:
>>> 1. Make sure that Object Model is in "call" scope and not in "pipelineComponent" one.
>>> 2. If there is still a problem, paste whole stack trace, then.
>> See above.
>
> Thanks Giacomo. Believe me or not, but I think we are much closer to the real cause of your
> troubles. In order to cast some spells on OM code I need to know how status.myTasks is put on OM AND
> how that snippet is called from the bits that need status.myTasks variable later on.
Ok, so this is the snippet where it is used:
<a href="view-my-tasks" id="view-my-tasks">
${status.myTasks.size()}
</a>
As it is part of the content surrounding of that page it was included by a XSLT via:
<ci:include element="status" src="cocoon:/user-status" />
which was processed by a
<map:match pattern="user-*">
<map:read src="screens/user-{1}.xml" />
</map:match>
and initially called by a flowscript that sets the status variable up as a native Javascript Hash
var status = { myTasks: taskManager.getTasks() };
whereas the taskManager.getTasks() returns a List
So the general process is that a flowscripts calls the pipeline descibed in my earlier mail with a
hash of informations where that pipeline expands the initial xml into cinclude which gets included
to the final page.
>
>>> Last thing, Giacomo, if you could respond to my mails more often we could find a solution for your
>>> troubles more quickly. ;)
>>> (take into account that I have exam tomorrow so I will respond on late afternoon, though)
>> I'll do my best ;-)
>
> Thanks! Tomorrow (Friday) I plan to work on Cocoon so I will be available whole day and I hope we
> will manage to push things forward. Sorry for your inconveniences.
NP, many thanks for looking at it. Hope my infos help you, otherwise just yell ;-)
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG6i3qLNdJvZjjVZARAjh5AJ9j6OTti72SjEcJjguqEqkK7R7P5wCdGhHi
bSf6YzAdjFsZ4eNH80UQ0Kw=
=tByw
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
> Here it is :-)
>
<snip/>
I agree, it's *ugly* :-)
> Caused by: org.apache.cocoon.el.ExpressionException: Couldn't evaluate expression status.myTasks.size()
> at org.apache.cocoon.el.impl.jexl.JexlExpression.evaluate(JexlExpression.java:50)
> at org.apache.cocoon.el.impl.jexl.JexlExpression.getNode(JexlExpression.java:82)
> at org.apache.cocoon.template.expression.JXTExpression.getNode(JXTExpression.java:72)
> at org.apache.cocoon.template.script.event.Characters.execute(Characters.java:58)
> ... 226 more
> Caused by: java.lang.NullPointerException
> at org.apache.commons.jexl.parser.ASTSizeFunction.sizeOf(ASTSizeFunction.java:77)
> at org.apache.commons.jexl.parser.ASTSizeMethod.execute(ASTSizeMethod.java:51)
> at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:68)
> at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:50)
> at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:86)
> at org.apache.cocoon.el.impl.jexl.JexlExpression.evaluate(JexlExpression.java:48)
> ... 229 more
I guess that you came across nasty bug in JEXL that tries to evaluate built-in functions on null values
and informs about it in very bad way.
The question is: where and how status.myTasks is supposed to be set? (see below, also)
<snip/>
> <map:match pattern="screen/**">
> <map:select type="resource-exists">
> <map:when test="{1}.xml">
> <map:generate src="{1}.xml" label="content" />
> </map:when>
> <map:otherwise>
> <map:generate src="servlet:bfabric-core:/screen/{1}" />
Let me guess: status.myTasks is called in that pipeline, right?
<snip/>
>
>> Not that much, unfortunately because it only shows that something is broken in pipelineComponent
>> scope code so no news here. I suggest to do three things:
>> 1. Make sure that Object Model is in "call" scope and not in "pipelineComponent" one.
>> 2. If there is still a problem, paste whole stack trace, then.
>
> See above.
Thanks Giacomo. Believe me or not, but I think we are much closer to the real cause of your
troubles. In order to cast some spells on OM code I need to know how status.myTasks is put on OM AND
how that snippet is called from the bits that need status.myTasks variable later on.
>> Last thing, Giacomo, if you could respond to my mails more often we could find a solution for your
>> troubles more quickly. ;)
>> (take into account that I have exam tomorrow so I will respond on late afternoon, though)
>
> I'll do my best ;-)
Thanks! Tomorrow (Friday) I plan to work on Cocoon so I will be available whole day and I hope we
will manage to push things forward. Sorry for your inconveniences.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>> I can say for the sitemap I've coded that there is no single map:mount
>
> I was asking if your sitemap that we (now) know both does not contain mounts is not mounted by other
> sitemap. It's crucial for now to eliminate map:mount as possible cause of trouble because if there
> is no map:mount you have probably found a bug.
>
>>> Is your sitemap managed by Servlet Service Framework?
>> If you mean by the org.apache.cocoon.sitemap.SitemapServlet bean, than yes, otherwise I'll need
>> more info on what you exactly mean by "Servlet Service Framework"
>
> Yes, I meant exactly that.
>> You felt my frustration now, which has cost me two days to realize that I cannot upgrade to newest
>> Cocoon. I was sure such thing shouldn't happen during RC release cycles anymore.
>
> Remember that current trunk is not RC2 yet. I has been aware of the fact that my code is in
> incomplete state and I was planning to complete it before RC2 or disable. However, it's better to
> put even incomplete code in the wild so any bugs (not the known limitations) can be spotted.
>
> I understand your frustration but you must remember that my GSoC work involved a *lot* of changes
> and major refactorings in very difficult parts of Cocoon so it's acceptable that there can be some
> bugs. Back-compatibility has been taken into account all the time, mainly thanks to Daniel's endless
> reminders.
>
>> Well, standard cocoon blocks mounted by DispatcherServlet into a standard cocoon-webapp (by
>> archetype) using different other blocks i.e. cocoon-auth
>
> Ok, that's very important information because I can be sure that everything is set up properly by
> DispatcherServlet and collaborating classes.
>
>> The stacktrace of the first request to standard Cocoon trunk is this:
>
> <snip/>
>
>> Caused by: java.lang.NullPointerException
>> at java.util.HashMap.putAll(HashMap.java:544)
>> at org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl.setParent(ObjectModelImpl.java:289)
>> at
>> org.apache.cocoon.components.pipeline.spring.PipelineComponentScope.get(PipelineComponentScope.java:51)
>
> This stack trace is when ObjectModel is in pipelineComponent scope. You said that after setting it
> to "call" there is some ugly stack trace and it's exactly that stack trace I was asking.
Here it is :-)
javax.servlet.ServletException: org.apache.cocoon.ProcessingException: Failed to process pipeline
at [TransformerException] - servlet:bfabric-core:/stylesheets/internal/document2page.xsl:33:70
at <map:serialize type="html4"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:279:55
at <map:transform type="servletLinkRewriter"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:264:61
at <map:transform type="encodeURL"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:149:47
at <map:transform type="servletLinkRewriter"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:148:57
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:138:68
at <map:transform type="i18n"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:133:40
at <map:transform type="browser-update"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:132:52
at <map:transform type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:131:40
at <map:transform type="cinclude"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:130:46
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:127:105
at <map:transform type="browser-update"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:262:56
at <map:transform type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:261:44
at <map:generate> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:255:71
at <map:match> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:252:44
at welcome -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/flow/view.js:251
at <map:call> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:636:50
at <map:match> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:635:34
at <map:act type="cauth-is-logged-in"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:563:48
at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:232)
at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:567)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy3.service(Unknown Source)
at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098)
at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:119)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: org.apache.cocoon.ProcessingException: Failed to process pipeline
at [TransformerException] - servlet:bfabric-core:/stylesheets/internal/document2page.xsl:33:70
at <map:serialize type="html4"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:279:55
at <map:transform type="servletLinkRewriter"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:264:61
at <map:transform type="encodeURL"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:149:47
at <map:transform type="servletLinkRewriter"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:148:57
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:138:68
at <map:transform type="i18n"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:133:40
at <map:transform type="browser-update"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:132:52
at <map:transform type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:131:40
at <map:transform type="cinclude"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:130:46
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:127:105
at <map:transform type="browser-update"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:262:56
at <map:transform type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:261:44
at <map:generate> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:255:71
at <map:match> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:252:44
at welcome -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/flow/view.js:251
at <map:call> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:636:50
at <map:match> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:635:34
at <map:act type="cauth-is-logged-in"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:563:48
at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:921)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:546)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:437)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:88)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.handleCocoonRedirect(ConcreteTreeProcessor.java:315)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:365)
at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:64)
at
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:201)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:706)
at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:718)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:471)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3085)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2251)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:161)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:159)
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:915)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:601)
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:123)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
... 30 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy18.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:542)
... 81 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 83 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy24.endDocument(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196)
at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:204)
at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:264)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:144)
... 88 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 105 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy29.endDocument(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy23.endDocument(Unknown Source)
... 110 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 117 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy26.endDocument(Unknown Source)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
at
org.apache.cocoon.template.xml.AttributeAwareXMLConsumerImpl.endDocument(AttributeAwareXMLConsumerImpl.java:58)
at org.apache.cocoon.template.script.event.EndDocument.execute(EndDocument.java:39)
at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:74)
at
org.apache.cocoon.template.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:152)
at
org.apache.cocoon.template.TransformerAdapter$TemplateConsumer.endDocument(TransformerAdapter.java:82)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
... 121 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 129 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy30.endDocument(Unknown Source)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy25.endDocument(Unknown Source)
... 133 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 139 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy14.endDocument(Unknown Source)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
at
org.apache.cocoon.ajax.BrowserUpdateTransformer.endDocument(BrowserUpdateTransformer.java:180)
... 143 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 146 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy20.endDocument(Unknown Source)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy13.endDocument(Unknown Source)
... 150 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 156 more
Caused by: org.apache.commons.lang.exception.NestableRuntimeException:
javax.xml.transform.TransformerException: java.lang.reflect.UndeclaredThrowableException
at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:578)
... 160 more
Caused by: javax.xml.transform.TransformerException: java.lang.reflect.UndeclaredThrowableException
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2416)
at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1374)
at
org.apache.xalan.templates.ElemApplyTemplates.transformSelectedNodes(ElemApplyTemplates.java:393)
at org.apache.xalan.templates.ElemApplyTemplates.execute(ElemApplyTemplates.java:176)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2281)
at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1367)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3458)
at
org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:406)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:560)
... 160 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy14.startElement(Unknown Source)
at org.apache.xml.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:204)
at org.apache.xml.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:277)
at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:243)
at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:1399)
at
org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2411)
... 170 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 176 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy31.startElement(Unknown Source)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy13.startElement(Unknown Source)
... 180 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 186 more
Caused by: org.apache.cocoon.ProcessingException: Failed to process pipeline
at [SAXParseException] - servlet:bfabric-core:/document/user-status:140:53
at <map:serialize type="xml-utf8"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:301:50
at <map:generate type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:298:92
at
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:559)
at
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258)
at
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460)
... 190 more
Caused by: org.apache.cocoon.ProcessingException: Failed to process pipeline
at [SAXParseException] - servlet:bfabric-core:/document/user-status:140:53
at <map:serialize type="xml-utf8"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:301:50
at <map:generate type="jx"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:298:92
at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:921)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:546)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:748)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.process(Unknown Source)
at org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:345)
at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:111)
at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:170)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:82)
at
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550)
... 192 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy34.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:542)
... 204 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 206 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy18.generate(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy33.generate(Unknown Source)
... 211 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 218 more
Caused by: org.apache.cocoon.el.ExpressionException: Couldn't evaluate expression status.myTasks.size()
at org.apache.cocoon.template.script.event.Characters.execute(Characters.java:61)
at org.apache.cocoon.template.script.Invoker.execute(Invoker.java:74)
at
org.apache.cocoon.template.JXTemplateGenerator.performGeneration(JXTemplateGenerator.java:152)
at org.apache.cocoon.template.JXTemplateGenerator.generate(JXTemplateGenerator.java:138)
... 223 more
Caused by: org.apache.cocoon.el.ExpressionException: Couldn't evaluate expression status.myTasks.size()
at org.apache.cocoon.el.impl.jexl.JexlExpression.evaluate(JexlExpression.java:50)
at org.apache.cocoon.el.impl.jexl.JexlExpression.getNode(JexlExpression.java:82)
at org.apache.cocoon.template.expression.JXTExpression.getNode(JXTExpression.java:72)
at org.apache.cocoon.template.script.event.Characters.execute(Characters.java:58)
... 226 more
Caused by: java.lang.NullPointerException
at org.apache.commons.jexl.parser.ASTSizeFunction.sizeOf(ASTSizeFunction.java:77)
at org.apache.commons.jexl.parser.ASTSizeMethod.execute(ASTSizeMethod.java:51)
at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:68)
at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:50)
at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:86)
at org.apache.cocoon.el.impl.jexl.JexlExpression.evaluate(JexlExpression.java:48)
... 229 more
>
> It would be helpful if you could paste relevant sitemap snippets, also.
There is a
<map:resource name="aggregate-html">
<map:select type="resource-exists">
<map:when test="stylesheets/document2page.xsl">
<map:transform src="stylesheets/document2page.xsl" />
</map:when>
<map:otherwise>
<map:transform
src="servlet:bfabric-core:/stylesheets/internal/document2page.xsl" />
</map:otherwise>
</map:select>
<map:transform type="cinclude" />
<map:transform type="jx" />
<map:transform type="browser-update" />
<map:transform type="i18n">
<map:parameter name="locale" value="{bfabric-locale:locale}" />
</map:transform>
<map:select type="resource-exists">
<map:when test="stylesheets/page2html.xsl">
<map:transform src="stylesheets/page2html.xsl">
<map:parameter name="locale" value="{bfabric-locale:locale}" />
</map:transform>
</map:when>
<map:otherwise>
<map:transform src="servlet:bfabric-core:/stylesheets/external/page2html.xsl">
<map:parameter name="locale" value="{bfabric-locale:locale}" />
</map:transform>
</map:otherwise>
</map:select>
<map:transform type="servletLinkRewriter" />
<map:transform type="encodeURL" />
</map:resource>
called by
<map:match pattern="screen/**">
<map:select type="resource-exists">
<map:when test="{1}.xml">
<map:generate src="{1}.xml" label="content" />
</map:when>
<map:otherwise>
<map:generate src="servlet:bfabric-core:/screen/{1}" />
</map:otherwise>
</map:select>
<map:transform type="jx" />
<map:transform type="browser-update" />
<map:call resource="aggregate-html" />
<map:transform type="servletLinkRewriter" />
<map:select type="ajax-request">
<map:when test="true"><!-- sending a partial Browser Update -->
<map:select type="request-parameter">
<map:parameter name="parameter-name" value="dojo.transport" />
<map:when test="iframe"><!-- sending BU via iFrameIO -->
<map:transform
src="servlet:forms:/resource/internal/xsl/IframeTransport-bu-styling.xsl" />
<map:serialize type="xhtml" /><!-- this is REALLY important -->
</map:when>
<map:otherwise><!-- sending BU via XHR -->
<map:serialize type="xml-utf8" />
</map:otherwise>
</map:select>
</map:when>
<map:otherwise><!-- sending a complete page -->
<map:serialize type="html4" />
</map:otherwise>
</map:select>
>
>> Maybe you can give a hint after this ;-)
>
> Not that much, unfortunately because it only shows that something is broken in pipelineComponent
> scope code so no news here. I suggest to do three things:
> 1. Make sure that Object Model is in "call" scope and not in "pipelineComponent" one.
> 2. If there is still a problem, paste whole stack trace, then.
See above.
>
> Remember that when you change scope back to "call" there is no way that the same error will appear
> as there will bo no setParent call.
>
> Last thing, Giacomo, if you could respond to my mails more often we could find a solution for your
> troubles more quickly. ;)
> (take into account that I have exam tomorrow so I will respond on late afternoon, though)
I'll do my best ;-)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG6A7pLNdJvZjjVZARAuFeAKC99Mp3ZjKB5i8RrDv1DlhecQgyZgCfXvf4
MXTFlwkDXdsZica7bGK7HF4=
=rMyh
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
> I can say for the sitemap I've coded that there is no single map:mount
I was asking if your sitemap that we (now) know both does not contain mounts is not mounted by other
sitemap. It's crucial for now to eliminate map:mount as possible cause of trouble because if there
is no map:mount you have probably found a bug.
>> Is your sitemap managed by Servlet Service Framework?
>
> If you mean by the org.apache.cocoon.sitemap.SitemapServlet bean, than yes, otherwise I'll need
> more info on what you exactly mean by "Servlet Service Framework"
Yes, I meant exactly that.
>
> You felt my frustration now, which has cost me two days to realize that I cannot upgrade to newest
> Cocoon. I was sure such thing shouldn't happen during RC release cycles anymore.
Remember that current trunk is not RC2 yet. I has been aware of the fact that my code is in
incomplete state and I was planning to complete it before RC2 or disable. However, it's better to
put even incomplete code in the wild so any bugs (not the known limitations) can be spotted.
I understand your frustration but you must remember that my GSoC work involved a *lot* of changes
and major refactorings in very difficult parts of Cocoon so it's acceptable that there can be some
bugs. Back-compatibility has been taken into account all the time, mainly thanks to Daniel's endless
reminders.
> Well, standard cocoon blocks mounted by DispatcherServlet into a standard cocoon-webapp (by
> archetype) using different other blocks i.e. cocoon-auth
Ok, that's very important information because I can be sure that everything is set up properly by
DispatcherServlet and collaborating classes.
> The stacktrace of the first request to standard Cocoon trunk is this:
<snip/>
> Caused by: java.lang.NullPointerException
> at java.util.HashMap.putAll(HashMap.java:544)
> at org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl.setParent(ObjectModelImpl.java:289)
> at
> org.apache.cocoon.components.pipeline.spring.PipelineComponentScope.get(PipelineComponentScope.java:51)
This stack trace is when ObjectModel is in pipelineComponent scope. You said that after setting it
to "call" there is some ugly stack trace and it's exactly that stack trace I was asking.
It would be helpful if you could paste relevant sitemap snippets, also.
> Maybe you can give a hint after this ;-)
Not that much, unfortunately because it only shows that something is broken in pipelineComponent
scope code so no news here. I suggest to do three things:
1. Make sure that Object Model is in "call" scope and not in "pipelineComponent" one.
2. If there is still a problem, paste whole stack trace, then.
Remember that when you change scope back to "call" there is no way that the same error will appear
as there will bo no setParent call.
Last thing, Giacomo, if you could respond to my mails more often we could find a solution for your
troubles more quickly. ;)
(take into account that I have exam tomorrow so I will respond on late afternoon, though)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>> Yes, I'm almost sure that's the reason why pipelineComponent scope is freaking.
>> Guess what ;-) didn't help removing all map:mount from the sitemap. Exception still exists and I
>> have still no clue what has caused this incompatability with existing code.
>
> Are you sure that there is no map:mount in whole call stack?
I can say for the sitemap I've coded that there is no single map:mount
> Is your sitemap managed by Servlet Service Framework?
If you mean by the org.apache.cocoon.sitemap.SitemapServlet bean, than yes, otherwise I'll need
more info on what you exactly mean by "Servlet Service Framework"
>
>> To be honest, I see no reason for me to dig into something I have not a single clue where to look
>> at. But still questioning who has put this backward incompatability into it and how to migrate from it.
>
> I think it's shared responsibility but the most significant part must be taken by me.
> I gave you description of current state of our code to help you get involved but only if you want
> to, of course. Nevertheless, I really, really want to avoid one-man shows as we both know that it's
> not how open source works. I can fix this myself (as soon as time permits) but this will not help
> situation that I and Daniel to some extent will have a any clue about this code.
You felt my frustration now, which has cost me two days to realize that I cannot upgrade to newest
Cocoon. I was sure such thing shouldn't happen during RC release cycles anymore.
> Implementing this sitemap scope is just a must in order to support old Cocoon code.
>
> In order to help you with migration I must get some details about your current setup and structure
> of application.
Well, standard cocoon blocks mounted by DispatcherServlet into a standard cocoon-webapp (by
archetype) using different other blocks i.e. cocoon-auth
>
>>> If you want to make a quick test if it's the only problem with current trunk and work-around NPE
>>> mentioned by you just change scope of ObjectModel from "pipelineComponent" to "call" in this
>>> file[1]. Be warned that it's only a quick work-around and implementation of sitemap scope is the
>>> only reliable solution.
>> Uhh, this give a even more ugly stacktrace (deep into template, el, and jexl) I wouldn't even think
>> of pasting it into this mail.
>
> It's your turn to be more informative, dear ;-)
> Paste this ugly stack trace, it may really help me to understand what's the real cause of your
> troubles. Take into account most (I haven't tested every single one) samples work with current code
> so it's something specific to your application/setup.
Yes, I know and thus my frustration not knowing what can cause it.
The stacktrace of the first request to standard Cocoon trunk is this:
org.apache.cocoon.ProcessingException: Failed to process pipeline
at <map:serialize type="html4"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:1294:43
at <map:transform type="servletLinkRewriter"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:1293:57
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:1283:68
at <map:transform> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:1276:107
at <map:transform type="i18n"> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:1266:40
at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.handleException(AbstractProcessingPipeline.java:921)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:546)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:437)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:567)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy3.service(Unknown Source)
at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098)
at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:119)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy11.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:542)
... 47 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 49 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy12.generate(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy10.generate(Unknown Source)
... 54 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
... 61 more
Caused by: org.apache.cocoon.ProcessingException: Sitemap: error invoking matcher
at <map:match> -
file:///home/giacomo/svn/otego/b-fabric/trunk/b-fabric-webapp/target/work/blocks/b-fabric-fgcz/sitemap.xmap:379:45
at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:111)
at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:90)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.buildPipeline(ConcreteTreeProcessor.java:187)
at org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:266)
at org.apache.cocoon.components.source.impl.SitemapSource.<init>(SitemapSource.java:147)
at
org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:65)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:152)
at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:182)
at org.apache.cocoon.sitemap.DefaultContentAggregator.setup(DefaultContentAggregator.java:289)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
at $Proxy12.setup(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy10.setup(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
at $Proxy11.setup(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:464)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:409)
... 46 more
Caused by: java.lang.NullPointerException
at java.util.HashMap.putAll(HashMap.java:544)
at org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl.setParent(ObjectModelImpl.java:289)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentScope.get(PipelineComponentScope.java:51)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:184)
at $Proxy1.markLocalContext(Unknown Source)
at org.apache.cocoon.components.treeprocessor.InvokeContext.pushMap(InvokeContext.java:234)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:51)
at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.buildPipeline(ConcreteTreeProcessor.java:187)
at org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:266)
at org.apache.cocoon.components.source.impl.SitemapSource.<init>(SitemapSource.java:147)
at
org.apache.cocoon.components.source.impl.SitemapSourceFactory.getSource(SitemapSourceFactory.java:65)
at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:152)
at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:182)
at org.apache.cocoon.sitemap.DefaultContentAggregator.setup(DefaultContentAggregator.java:289)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
at $Proxy12.setup(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy10.setup(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.components.pipeline.spring.PipelineComponentProxyDecorator$ScopeChangerProxy.invoke(PipelineComponentProxyDecorator.java:86)
at $Proxy11.setup(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:464)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:409)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.process(Unknown Source)
at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:567)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy3.service(Unknown Source)
at org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1098)
at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:119)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Maybe you can give a hint after this ;-)
Ciao and thanks
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG5/QLLNdJvZjjVZARAuenAKC2uFjc7A1VedeRbTSauvlwjcRVAgCgityV
BBF97TlKqASskxniYvgA8g4=
=mu/V
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>> Yes, I'm almost sure that's the reason why pipelineComponent scope is freaking.
>
> Guess what ;-) didn't help removing all map:mount from the sitemap. Exception still exists and I
> have still no clue what has caused this incompatability with existing code.
Are you sure that there is no map:mount in whole call stack? Is your sitemap managed by Servlet
Service Framework?
>
> To be honest, I see no reason for me to dig into something I have not a single clue where to look
> at. But still questioning who has put this backward incompatability into it and how to migrate from it.
I think it's shared responsibility but the most significant part must be taken by me.
I gave you description of current state of our code to help you get involved but only if you want
to, of course. Nevertheless, I really, really want to avoid one-man shows as we both know that it's
not how open source works. I can fix this myself (as soon as time permits) but this will not help
situation that I and Daniel to some extent will have a any clue about this code.
Implementing this sitemap scope is just a must in order to support old Cocoon code.
In order to help you with migration I must get some details about your current setup and structure
of application.
>> If you want to make a quick test if it's the only problem with current trunk and work-around NPE
>> mentioned by you just change scope of ObjectModel from "pipelineComponent" to "call" in this
>> file[1]. Be warned that it's only a quick work-around and implementation of sitemap scope is the
>> only reliable solution.
>
> Uhh, this give a even more ugly stacktrace (deep into template, el, and jexl) I wouldn't even think
> of pasting it into this mail.
It's your turn to be more informative, dear ;-)
Paste this ugly stack trace, it may really help me to understand what's the real cause of your
troubles. Take into account most (I haven't tested every single one) samples work with current code
so it's something specific to your application/setup.
Most important: can you reproduce this behaviour when developing some simple test based on our
archetype?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Grzegorz Kossakowski wrote:
>>>
>> <map:match pattern="*/**">
>> <map:mount uri-prefix="{1}" src="blockcontext:/{1}/" />
>> </map:match>
>>
>> Is that causing the troubles?
>
> Yes, I'm almost sure that's the reason why pipelineComponent scope is freaking.
Guess what ;-) didn't help removing all map:mount from the sitemap. Exception still exists and I
have still no clue what has caused this incompatability with existing code.
> Both cocoon: source and <map:mount/> are considered old-fashioned if we have Servlet Service
> Framework that does the same in more clear and powerful way. Independently from our preferences, we
> need to support both cocoon: and <map:mount/>, obviously. In order to provide back-compatibility we
> need to implement sitemap scope (see COCOON-2099).
> If you are going to make effort of implementing this scope, don't forget to assign that issue to
> yourself. I unassigned it because my list of assigned issues is already long and I'm overwhelmed
> with other affairs.
To be honest, I see no reason for me to dig into something I have not a single clue where to look
at. But still questioning who has put this backward incompatability into it and how to migrate from it.
> If you want to make a quick test if it's the only problem with current trunk and work-around NPE
> mentioned by you just change scope of ObjectModel from "pipelineComponent" to "call" in this
> file[1]. Be warned that it's only a quick work-around and implementation of sitemap scope is the
> only reliable solution.
Uhh, this give a even more ugly stacktrace (deep into template, el, and jexl) I wouldn't even think
of pasting it into this mail.
> HTH.
Unfortunately it didn't at all!
> [1]
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/ObjectModel.xml
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG5n2kLNdJvZjjVZARAk5HAKCfC+Hfr5kDy8FCzbJLfCcYIyVOugCgsZzL
Dlm9N6TITh9tfjAyvflMpzY=
=6XNV
-----END PGP SIGNATURE-----