You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2007/09/19 13:28:15 UTC
Re: pipelineComponent scope troubles (was Code freeze?)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Felix Knecht wrote:
>> Is this failing test case a blocker for the release? In my opinion not
>> because everything else seems to work.
>>
>> WDOT?
>>
> I don't think it's a blocker:
> 1. We wouldn't be the only ones releasing (just in case it's a real bug
> and not a testcase problem) and having a release note with already known
> bugs.
> 2. It's a RC (2). Why are (just in case) already known bugs not allowed?
> 3. It would be really nice to see the RC2 released for the CocoonGT
> (Please go ahead with the release.)!
> 4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
> a problem than the zipper stuff.
Felix
As you have a similar environment as I have, could you give the sample from Grzegorz a try with the
latest trunk (including changes from Grzegorz of today)?
First build (mvn clean install) myBlock2, than myBlock1, and afterwards myCocoonWebapp. Let it run
and point to http://localhost:8888/myBlock2/screens/obtain-data to see whether you get an Exception
or data.
TIA
- --
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)
iD8DBQFG8QfPLNdJvZjjVZARAn+VAKCiQ8gViZlM8+oF7RiLHBZL3Do01gCeKKJE
N6To1VPPVtLYZWgowty4hdc=
=dSUj
-----END PGP SIGNATURE-----
Finishing the 2.2-RC2 release (was Re: pipelineComponent scope troubles)
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Leszek Gawron pisze:
>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>> exception you probably called
>>> Source.getInputStream even though the source reported proper validity.
>>> The only way to solve this
>>> is to implement a resource heavy version of postable source.:
>>> javax.servlet.ServletException: If
>>> you see this exception you probably called Source.getInputStream even
>>> though the source reported
>>> proper validity. The only way to solve this is to implement a resource
>>> heavy version of postable
>>> source.
>> this probably means we will not be able to implement fully pipelined
>> servlet services.. I have reverted the change we did at GT.
>
> Very unfortunate news but I don't think situation is hopeless.
>
> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
> Giacomo, does everything work for you after Leszek reverted his changes?
Grek, in the case that Giacomo's answer is yes, could you please branch the
affacted modules from /tags/cocoon-2.2/???/[version] to
/branches/cocoon-2.2/???/[version] and apply your patch(es) their too? Then I
could recreate the release artifacts and we can start to test them.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Grzegorz Kossakowski wrote:
>>> Giacomo, Felix: Could you confirm that everything works for you if
>>> you stick to 1.0.0 version of
>>> template so we can release Cocoon 2.2 RC2?
>>
>> Actually we don't have the problem as the situation when mentioned NPE
>> happens is not used by our
>> app and thus we run fine with HEAD.
>
> I am a little bit confused. Is there still a problem? If so does if
> affect 1.0.0 branch or trunk version of cocoon-template?
Well, currently we run from trunk and it seem to work so far.
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.7 (GNU/Linux)
iD8DBQFHIfC8LNdJvZjjVZARAskaAKCqX7U0MSAdrce3N0oJCJUKK4qHOgCg0dl3
WZghfYenztocotVza5+1Cus=
=xg8H
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Grzegorz Kossakowski wrote:
>> Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
>> template so we can release Cocoon 2.2 RC2?
>
> Actually we don't have the problem as the situation when mentioned NPE happens is not used by our
> app and thus we run fine with HEAD.
I am a little bit confused. Is there still a problem? If so does if
affect 1.0.0 branch or trunk version of cocoon-template?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
>
> Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
> template so we can release Cocoon 2.2 RC2?
Actually we don't have the problem as the situation when mentioned NPE happens is not used by our
app and thus we run fine with HEAD.
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.7 (GNU/Linux)
iD8DBQFHDIuZLNdJvZjjVZARAgSFAKDdkDavg9CsAA2cV29Gm1W7tqBznQCgmi5f
e/0UX0QiGZKKlQLkcg3sed8=
=Bk1x
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
>
> It seems that the JXGenerator stopped working.
>
> Changing the generation part in the sitemap [1] from
>
> <snip>
>
> <map:match pattern="*-display-pipeline.jx">
> <map:generate type="jx" src="forms/{1}_template.xml" label="content1">
> <map:parameter name="locale" value="{flow-attribute:locale}" />
> </map:generate>
>
> </snip>
>
> to
>
> <map:match pattern="*-display-pipeline.jx">
> <map:generate src="forms/{1}_template.xml" label="content1">
> <map:parameter name="locale" value="{flow-attribute:locale}" />
> </map:generate>
> <map:transform type="jx" />
>
> made sample working again.
>
> It looks like the properties from the bean definition
> (saxParser,scriptManager, ObjectModel) are not set when the
> JXTemplateGenerator.setup(...) is called and therefor
>
> this.startDocument = scriptManager.resolveTemplate(src);
>
> throws Exception below because scriptManager = null.
>
>
>
> Caused by: java.lang.NullPointerException
> at
> org.apache.cocoon.template.JXTemplateGenerator.setup(JXTemplateGenerator.java:117)
> 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:597)
> at
> org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
> at $Proxy9.setup(Unknown Source)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
Yep, I dug into this problem too and shared my thoughts in a new thread:
http://article.gmane.org/gmane.text.xml.cocoon.devel/75588
As for now I think you can safely stick to 1.0.0 version of template block and update your application.
Giacomo, Felix: Could you confirm that everything works for you if you stick to 1.0.0 version of
template so we can release Cocoon 2.2 RC2?
(actually, this situation proves that branching is quite good idea and Springification is not always
such a straightforward process as we thought)
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Felix Knecht <fe...@otego.com>.
>
> Even Felix can now run our app without the known hassles and exceptions. But we don't know whether
> to migrate as now some of the CForm samples throw exceptions they didn't after my springification.
>
> Any ideas what caused the samples to stop working?
>
It seems that the JXGenerator stopped working.
Changing the generation part in the sitemap [1] from
<snip>
<map:match pattern="*-display-pipeline.jx">
<map:generate type="jx" src="forms/{1}_template.xml" label="content1">
<map:parameter name="locale" value="{flow-attribute:locale}" />
</map:generate>
</snip>
to
<map:match pattern="*-display-pipeline.jx">
<map:generate src="forms/{1}_template.xml" label="content1">
<map:parameter name="locale" value="{flow-attribute:locale}" />
</map:generate>
<map:transform type="jx" />
made sample working again.
It looks like the properties from the bean definition
(saxParser,scriptManager, ObjectModel) are not set when the
JXTemplateGenerator.setup(...) is called and therefor
this.startDocument = scriptManager.resolveTemplate(src);
throws Exception below because scriptManager = null.
Caused by: java.lang.NullPointerException
at
org.apache.cocoon.template.JXTemplateGenerator.setup(JXTemplateGenerator.java:117)
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:597)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
at $Proxy9.setup(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:341)
Felix
[1]
blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/sitemap.xmap
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
>
>
> Grzegorz Kossakowski wrote:
>> Leszek Gawron pisze:
>>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>>> exception you probably called
>>>> Source.getInputStream even though the source reported proper validity.
>>>> The only way to solve this
>>>> is to implement a resource heavy version of postable source.:
>>>> javax.servlet.ServletException: If
>>>> you see this exception you probably called Source.getInputStream even
>>>> though the source reported
>>>> proper validity. The only way to solve this is to implement a resource
>>>> heavy version of postable
>>>> source.
>>> this probably means we will not be able to implement fully pipelined
>>> servlet services.. I have reverted the change we did at GT.
>> Very unfortunate news but I don't think situation is hopeless.
>
>> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
>> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
>> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
>> Giacomo, does everything work for you after Leszek reverted his changes?
>
> I'm still testing after Leszek reverted his changes and suprisingly our app seems to work now
> (whatever change or revert made it happen) ?!?!?!
>
> I'll give more info as soon as I've finished testing our app with latest Cocoon
Even Felix can now run our app without the known hassles and exceptions. But we don't know whether
to migrate as now some of the CForm samples throw exceptions they didn't after my springification.
Any ideas what caused the samples to stop working?
- --
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.7 (GNU/Linux)
iD8DBQFHCyp2LNdJvZjjVZARAiidAJ4ojXh750dL6ohL2rjeymCt/qqptwCg1r7m
M+MEQ92qHv4dFsDiZcxY9dk=
=3AJl
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Leszek Gawron pisze:
>>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>>> exception you probably called
>>> Source.getInputStream even though the source reported proper validity.
>>> The only way to solve this
>>> is to implement a resource heavy version of postable source.:
>>> javax.servlet.ServletException: If
>>> you see this exception you probably called Source.getInputStream even
>>> though the source reported
>>> proper validity. The only way to solve this is to implement a resource
>>> heavy version of postable
>>> source.
>> this probably means we will not be able to implement fully pipelined
>> servlet services.. I have reverted the change we did at GT.
>
> Very unfortunate news but I don't think situation is hopeless.
>
> Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
> could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
> now it's going to be hard to figure out what's the possible problem with servlet protocol.
>
> Giacomo, does everything work for you after Leszek reverted his changes?
I'm still testing after Leszek reverted his changes and suprisingly our app seems to work now
(whatever change or revert made it happen) ?!?!?!
I'll give more info as soon as I've finished testing our app with latest Cocoon
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.7 (GNU/Linux)
iD8DBQFHCyI4LNdJvZjjVZARAhxkAKC6E6CtiQvOmimVqYFqb0C9i6wiLwCghYOZ
Pb/QhMdqO/Pl00K12Fzjpio=
=L/xL
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Leszek Gawron pisze:
>>
>> Caused by: org.apache.cocoon.CascadingIOException: If you see this
>> exception you probably called
>> Source.getInputStream even though the source reported proper validity.
>> The only way to solve this
>> is to implement a resource heavy version of postable source.:
>> javax.servlet.ServletException: If
>> you see this exception you probably called Source.getInputStream even
>> though the source reported
>> proper validity. The only way to solve this is to implement a resource
>> heavy version of postable
>> source.
>
> this probably means we will not be able to implement fully pipelined
> servlet services.. I have reverted the change we did at GT.
Very unfortunate news but I don't think situation is hopeless.
Anyway, my opinion is that we should just start with buffer and after servlet-service stabilizes. We
could continue improving servlet protocol performance. Otherwise, if we are going to complicate it
now it's going to be hard to figure out what's the possible problem with servlet protocol.
Giacomo, does everything work for you after Leszek reverted his changes?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Giacomo Pati wrote:
>>
>> Grzegorz Kossakowski wrote:
>>
>>> Giacomo, sorry that it took me so long to take a look at this but
>>> CocoonGT was quite involving event. It certainly was worth the effort I
>>> put to get there! :)
>> NP. Hope you enjoyed GT.
>>
>>> Getting back to the topic. I think I found cause of all problems people
>>> were having and it turns out that I forgot that cocoon: protocol has
>>> insanely complicated flow so all decent assumptions about our
>>> environment do not work when it is used.
>>> I believe that the changed I committed in r582629 fixes all troubles. At
>>> least your sample is working now returning such result:
>>> <?xml version="1.0" encoding="ISO-8859-1"?><status
>>> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>>> <body>
>>> <count>3</count>
>>> <size>2</size>
>>> </body>
>>> </document></status>
>>> Is it what you expected? Could give it little more testing? Actually
>>> this issue blocks whole RC2 so haste is advisable here.
>> Thanks alot! I'll take a look at it this today.
>
> Actually I get mostly:
>
> org.apache.cocoon.CascadingIOException: If you see this exception you probably called
> Source.getInputStream even though the source reported proper validity. The only way to solve this
> is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
> you see this exception you probably called Source.getInputStream even though the source reported
> proper validity. The only way to solve this is to implement a resource heavy version of postable
> source.
>
> on things which were valid before.
>
> Any hints?
>
> Relevant stack trace:
>
> Caused by: org.apache.cocoon.CascadingIOException: If you see this exception you probably called
> Source.getInputStream even though the source reported proper validity. The only way to solve this
> is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
> you see this exception you probably called Source.getInputStream even though the source reported
> proper validity. The only way to solve this is to implement a resource heavy version of postable
> source.
this probably means we will not be able to implement fully pipelined
servlet services.. I have reverted the change we did at GT.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
>
>
> Grzegorz Kossakowski wrote:
>
>> Giacomo, sorry that it took me so long to take a look at this but
>> CocoonGT was quite involving event. It certainly was worth the effort I
>> put to get there! :)
>
> NP. Hope you enjoyed GT.
>
>> Getting back to the topic. I think I found cause of all problems people
>> were having and it turns out that I forgot that cocoon: protocol has
>> insanely complicated flow so all decent assumptions about our
>> environment do not work when it is used.
>> I believe that the changed I committed in r582629 fixes all troubles. At
>> least your sample is working now returning such result:
>> <?xml version="1.0" encoding="ISO-8859-1"?><status
>> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
>> <body>
>> <count>3</count>
>> <size>2</size>
>> </body>
>> </document></status>
>
>> Is it what you expected? Could give it little more testing? Actually
>> this issue blocks whole RC2 so haste is advisable here.
>
> Thanks alot! I'll take a look at it this today.
Actually I get mostly:
org.apache.cocoon.CascadingIOException: If you see this exception you probably called
Source.getInputStream even though the source reported proper validity. The only way to solve this
is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
you see this exception you probably called Source.getInputStream even though the source reported
proper validity. The only way to solve this is to implement a resource heavy version of postable
source.
on things which were valid before.
Any hints?
Relevant stack trace:
Caused by: org.apache.cocoon.CascadingIOException: If you see this exception you probably called
Source.getInputStream even though the source reported proper validity. The only way to solve this
is to implement a resource heavy version of postable source.: javax.servlet.ServletException: If
you see this exception you probably called Source.getInputStream even though the source reported
proper validity. The only way to solve this is to implement a resource heavy version of postable
source.
at
org.apache.cocoon.servletservice.components.ServletSource.getInputStream(ServletSource.java:89)
at org.apache.cocoon.components.source.util.SourceUtil.getInputSource(SourceUtil.java:428)
at org.apache.cocoon.components.source.util.SourceUtil.parse(SourceUtil.java:297)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:144)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:331)
... 143 more
The FileGenerator in question has:
<map:generate src="servlet:myBlock2:/user-status" />
- --
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.7 (GNU/Linux)
iD8DBQFHCgZ6LNdJvZjjVZARAghoAJ4wNVH+JFiP3yUnVlaMuDy19ce0ygCdEe91
h/4Xx1HjIZnyJf4leuOcYyg=
=55Lm
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo, sorry that it took me so long to take a look at this but
> CocoonGT was quite involving event. It certainly was worth the effort I
> put to get there! :)
NP. Hope you enjoyed GT.
> Getting back to the topic. I think I found cause of all problems people
> were having and it turns out that I forgot that cocoon: protocol has
> insanely complicated flow so all decent assumptions about our
> environment do not work when it is used.
> I believe that the changed I committed in r582629 fixes all troubles. At
> least your sample is working now returning such result:
> <?xml version="1.0" encoding="ISO-8859-1"?><status
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
> <body>
> <count>3</count>
> <size>2</size>
> </body>
> </document></status>
>
> Is it what you expected? Could give it little more testing? Actually
> this issue blocks whole RC2 so haste is advisable here.
Thanks alot! I'll take a look at it this today.
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.7 (GNU/Linux)
iD8DBQFHCbpOLNdJvZjjVZARArdrAKCwRGV0/p5rfxHwzmFCtAHuwwlCCACgt5Hx
HmPMa3rZCI15m+SiYtoAoC0=
=qC4y
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Giacomo Pati pisze:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Grzegorz Kossakowski wrote:
>> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
>> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
>> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
>> just consider debugging Jexl yourself, it's has source code written decently.
>
> I've setup a stripped down to bare minimum sample (based on your little sample) that has the
> behaviour as our application. I can confirm, that this sample works with trunk upto revision
> 567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
Giacomo, sorry that it took me so long to take a look at this but
CocoonGT was quite involving event. It certainly was worth the effort I
put to get there! :)
Getting back to the topic. I think I found cause of all problems people
were having and it turns out that I forgot that cocoon: protocol has
insanely complicated flow so all decent assumptions about our
environment do not work when it is used.
I believe that the changed I committed in r582629 fixes all troubles. At
least your sample is working now returning such result:
<?xml version="1.0" encoding="ISO-8859-1"?><status
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0"><document
xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
<body>
<count>3</count>
<size>2</size>
</body>
</document></status>
Is it what you expected? Could give it little more testing? Actually
this issue blocks whole RC2 so haste is advisable here.
Thanks for your patience.
--
Grzegorz Kossakowski
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz pisze:
>
> Caused by: java.lang.NullPointerException
> at org.apache.cocoon.callstack.CallScope.get(CallScope.java:37)
>
> It can easily be reproduced by adding this pipeline to a Cocoon 2.2 app
> created by the Cocoon 2.2 archetype:
>
> <map:match pattern="fails">
> <map:generate src="cocoon:/spring-bean"/>
> <map:serialize type="xml"/>
> </map:match>
It wasn't serious but I fixed it (by disabling
PipelineComponentProxyDecorator) in r582628.
Thanks for reporting.
--
Grzegorz Kossakowski
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> Grzegorz Kossakowski wrote:
>> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
>> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
>> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
>> just consider debugging Jexl yourself, it's has source code written decently.
>
> I've setup a stripped down to bare minimum sample (based on your little sample) that has the
> behaviour as our application. I can confirm, that this sample works with trunk upto revision
> 567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
I don't know if it is related but if I use the cocoon protocol to call a
pipeline that uses a jx-template, the template doesn't receive the passed
objects anymore. I think that's the relevant part of the stacktrace:
Caused by: java.lang.NullPointerException
at org.apache.cocoon.callstack.CallScope.get(CallScope.java:37)
It can easily be reproduced by adding this pipeline to a Cocoon 2.2 app created
by the Cocoon 2.2 archetype:
<map:match pattern="fails">
<map:generate src="cocoon:/spring-bean"/>
<map:serialize type="xml"/>
</map:match>
--
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 (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
> passed but everything works fine. Is your list a standard Java implementation like ArrayList?
> Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
> just consider debugging Jexl yourself, it's has source code written decently.
I've setup a stripped down to bare minimum sample (based on your little sample) that has the
behaviour as our application. I can confirm, that this sample works with trunk upto revision
567300. You'll find it at http://people.apache.org/~giacomo/c2.2-test.tar.gz
HTH and MTIA
- --
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)
iD8DBQFG96fVLNdJvZjjVZARApDvAKDaG/DTbXqfv7k9YOn5H3pJu7LyZwCfRJxD
bIEHV4c7Esf4jA9U/ssWak8=
=qjEq
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
> I've tried current trunk as well and it seems that the stack trace I've
> reported earlier is gone now and I'm again at the NPE from jexl. After
> some debugging as you told me, I can confirm that the failing request of
> my app is using the one and only OM instance created during that
> request. I can also see the status object being put into it and fetched
> later again with a "myTasks" attribute which _is_ a List having a size
> of 0
Good to hear that. We have at least can remove large portion of code from the list of suspected.
> but jexl still barfs the NPE "cannot evaluate
> 'status.myTasks.size()'?!?!?! Which makes me believe it could be a Jexl
> problem. Did we changed Jexl version???
>
> I'm stuck again.
I'm sure that we have not upgraded Jexl for at least three months.
Any chance to reproduce this behaviour with my little sample? I tried to modify it so empty List is
passed but everything works fine. Is your list a standard Java implementation like ArrayList?
Isolating the problem that anyone can test on its own machine is crucial here, really. Or you can
just consider debugging Jexl yourself, it's has source code written decently.
Thank you for quick response.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@otego.com>.
On Thu, 20 Sep 2007, Grzegorz Kossakowski wrote:
> Date: Thu, 20 Sep 2007 18:54:24 +0200
> From: Grzegorz Kossakowski <gk...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: pipelineComponent scope troubles (was Code freeze?)
>
> Grzegorz Kossakowski pisze:
>>
>> When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
>> I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
>> thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
>> fix while upgrading my hardware...
>>
>> I'm going to find a proper fix now. Thanks for reporting.
>
> Ehkm. After digging the code I came to conclusion that this issue has been fixed, after all...
>
> The fix was pretty naive and made in r567433 (my next commit after r567329), see:
> http://article.gmane.org/gmane.text.xml.cocoon.cvs/25006
I've tried current trunk as well and it seems that the stack trace I've
reported earlier is gone now and I'm again at the NPE from jexl. After
some debugging as you told me, I can confirm that the failing request of
my app is using the one and only OM instance created during that request.
I can also see the status object being put into it and fetched later again
with a "myTasks" attribute which _is_ a List having a size of 0 but jexl
still barfs the NPE "cannot evaluate 'status.myTasks.size()'?!?!?!
Which makes me believe it could be a Jexl problem. Did we changed Jexl
version???
I'm stuck again.
--
Otego AG Tel: +41 (0)1 240 00 55
Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member Mailto:giacomo@apache.org
Hohlstrasse 216 Mailto:Giacomo.Pati@otego.com
CH-8004 Zürich http://www.otego.com
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
>
> When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
> I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
> thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
> fix while upgrading my hardware...
>
> I'm going to find a proper fix now. Thanks for reporting.
Ehkm. After digging the code I came to conclusion that this issue has been fixed, after all...
The fix was pretty naive and made in r567433 (my next commit after r567329), see:
http://article.gmane.org/gmane.text.xml.cocoon.cvs/25006
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
>
> Giacomo Pati wrote:
>
> <snip-all>
>
> I've isolated the culprit commit that caused our application to stop working. Our application works
> fine up to and excluding commit r567329 which was
> http://article.gmane.org/gmane.text.xml.cocoon.cvs/24998/match=r567329:
>
> cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/treeprocessor/InvokeContext.java
> Sat Aug 18 14:12:45 2007
>> @@ -231,6 +231,8 @@
>> final String sitemapObjectModelPathPrefix = "sitemap";
>> final String sitemapObjectModelNamedPathPrefix = sitemapObjectModelPathPrefix + "/$named$";
>
>> + newObjectModel.markLocalContext();
>> +
>> this.mapStack.add(map);
>
>> if (getLogger().isDebugEnabled()) {
>> @@ -292,6 +294,7 @@
>> Object name = this.mapToName.get(map);
>> this.mapToName.remove(map);
>> this.nameToMap.remove(name);
>> + this.newObjectModel.cleanupLocalContext();
>> }
>
>
> Looking at the commit above and the stack trace we have got
>
> Caused by: java.lang.UnsupportedOperationException
> at org.apache.commons.collections.map.UnmodifiableMap.remove(UnmodifiableMap.java:115)
> at
> org.apache.commons.collections.map.AbstractMapDecorator.remove(AbstractMapDecorator.java:114)
> at org.apache.cocoon.objectmodel.ObjectModelImpl.removeAt(ObjectModelImpl.java:167)
> at org.apache.cocoon.objectmodel.ObjectModelImpl.cleanupLocalContext(ObjectModelImpl.java:177)
>
> it seams that the cleanupLocalContext() method will modify a UnmodifiableMap which of cource will
> produce this exception.
>
> Now, before I'll dig into it, I'll ask here whether this is something obvious to someone?
>
> Ciao and thanks
Giacomo, I'm lost with your issues. What about NPE you had, what about my sample? Does this work for
you, now?
When looking at this issue and the stacktrace you have given above I'm feeling like having Déjà vu.
I have experienced problem with UnmodifiableMap at the time I made the commit you mentioned and I
thought that I had fixed it immediately. It turns out that I must have forgot to do it and lost my
fix while upgrading my hardware...
I'm going to find a proper fix now. Thanks for reporting.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Giacomo Pati wrote:
<snip-all>
I've isolated the culprit commit that caused our application to stop working. Our application works
fine up to and excluding commit r567329 which was
http://article.gmane.org/gmane.text.xml.cocoon.cvs/24998/match=r567329:
cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/components/treeprocessor/InvokeContext.java
Sat Aug 18 14:12:45 2007
> @@ -231,6 +231,8 @@
> final String sitemapObjectModelPathPrefix = "sitemap";
> final String sitemapObjectModelNamedPathPrefix = sitemapObjectModelPathPrefix + "/$named$";
>
> + newObjectModel.markLocalContext();
> +
> this.mapStack.add(map);
>
> if (getLogger().isDebugEnabled()) {
> @@ -292,6 +294,7 @@
> Object name = this.mapToName.get(map);
> this.mapToName.remove(map);
> this.nameToMap.remove(name);
> + this.newObjectModel.cleanupLocalContext();
> }
Looking at the commit above and the stack trace we have got
Caused by: java.lang.UnsupportedOperationException
at org.apache.commons.collections.map.UnmodifiableMap.remove(UnmodifiableMap.java:115)
at
org.apache.commons.collections.map.AbstractMapDecorator.remove(AbstractMapDecorator.java:114)
at org.apache.cocoon.objectmodel.ObjectModelImpl.removeAt(ObjectModelImpl.java:167)
at org.apache.cocoon.objectmodel.ObjectModelImpl.cleanupLocalContext(ObjectModelImpl.java:177)
it seams that the cleanupLocalContext() method will modify a UnmodifiableMap which of cource will
produce this exception.
Now, before I'll dig into it, I'll ask here whether this is something obvious to someone?
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)
iD8DBQFG8m+zLNdJvZjjVZARApWjAKC5u3j4fyqaLjhArbtZVmMBMffOjQCgpgFN
L3apJJhlEh8bxVfZy72v14w=
=FMhy
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, thanks. So we have at least 2 machines where current trunk isn't running correctly. And as
Linux is probably the most used target platform I categorize it as a serious problem.
Is there anybody having success on Linux?
Felix Knecht wrote:
> Giacomo Pati schrieb:
>> Felix
>>
>> As you have a similar environment as I have, could you give the sample
>> from Grzegorz a try with the
>> latest trunk (including changes from Grzegorz of today)?
>>
> Yes of course
>
>> First build (mvn clean install) myBlock2, than myBlock1, and
>> afterwards myCocoonWebapp. Let it run
>> and point to http://localhost:8888/myBlock2/screens/obtain-data to see
>> whether you get an Exception
>> or data.
>>
> I still get an Exception, see log [1].
>
> I cleaned local maven repo and rebuild latest svn co of cocoon trunk
> r577240 with sun-jdk-1.6.0_02
>
> [1] http://people.apache.org/~felixk/GrekSample_001.log
>
> PS:
> Of course now the zip... testcase fails under linux because of commit
> 577108 again ;-)
>
- --
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)
iD8DBQFG8RC3LNdJvZjjVZARAnuHAKCwzd4KUcXHBEwUtgJEK7F04elHawCeLlWt
wC1SKi9cMPH/iYo+eMVi7xU=
=Dpu5
-----END PGP SIGNATURE-----
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.09.2007 7:54 Uhr, Felix Knecht wrote:
> PS:
> Of course now the zip... testcase fails under linux because of commit
> 577108 again ;-)
You can easily fix this by adding the slash back to the test case locally.
Joerg
Re: pipelineComponent scope troubles (was Code freeze?)
Posted by Felix Knecht <fe...@apache.org>.
Giacomo Pati schrieb:
>
> Felix
>
> As you have a similar environment as I have, could you give the sample
> from Grzegorz a try with the
> latest trunk (including changes from Grzegorz of today)?
>
Yes of course
> First build (mvn clean install) myBlock2, than myBlock1, and
> afterwards myCocoonWebapp. Let it run
> and point to http://localhost:8888/myBlock2/screens/obtain-data to see
> whether you get an Exception
> or data.
>
I still get an Exception, see log [1].
I cleaned local maven repo and rebuild latest svn co of cocoon trunk
r577240 with sun-jdk-1.6.0_02
[1] http://people.apache.org/~felixk/GrekSample_001.log
PS:
Of course now the zip... testcase fails under linux because of commit
577108 again ;-)