cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject Re: c3: null pointer exception in ResponseHeaderCollector.isModifiedResponse
Date Mon, 26 Mar 2012 16:47:13 GMT
On 03/26/2012 04:49 PM, Francesco Chicchiriccò wrote:
> On 26/03/2012 16:42, Lars Huttar wrote:
>> I sent this email at the start of the weekend, so it may not have been
>> seen much.
>> However the NPE is blocking progress, so I'd like to see if anyone can
>> help me with it.
>> Anybody have ideas?
> Lars,
> do you have any chance to share your project somewhere (github,
> gitorius...) so that it would be much easier to take a look at it?
>
>> After the difficulties of the last week or two, I'm starting to wonder
>> if we'd be better off going back to Cocoon 2.1.11. A colleague asked
>> me, why take the risk and time to move to Cocoon 3, when we have
>> Cocoon 2.1.11 working well? I gave the standard "2.1.11 is several
>> years old and will be increasingly unsupported" answer, but I had to
>> admit that the decision was not looking as good now as it seemed last
>> summer when C3 had a recent new alpha and even a beta candidate.
>>
>> Please don't take this as criticism of the Cocoon developers ... I
>> have been continually impressed at the readiness of the committers to
>> debug problems quickly and implement fixes. However I do wonder
>> whether there is just too much debugging left, to reach a stable state
>> in time for our work. Also I am concerned that since there doesn't
>> seem to be a roadmap for feature freeze, there may be no point at
>> which bugs will settle down so that a stable release can be completed.
> Cocoon 3 is alpha state, but you are working on a SNAPSHOT release of
> beta-1: this means that Cocoon 3.0 does not pretend - yet - to be
> officially stable.
>
> Despite of this, I can assure that my company and at least a couple of
> other companies have several production applications based on Cocoon
> 3.0, so my suggestion would be "keep pushing" ;-)

This said, I should have said much earlier something but the discussion 
about c3 belongs on the dev list until we have an official release. If 
you want to keep up with your development I strongly recommend to sync 
c3 trunk regular.

Now to the NPE, without seeing the code is hard to say something but

<!-- {map:1} = generator name, {map:2} = param, {map:3} = value -->
<map:match pattern="generator/*/*/*/source">
<map:generate src="generators/{map:1}.xml" />
<map:serialize type="xml"/>
</map:match>

resolves


2012-03-23 14:33:30,598 DEBUG 11202659@qtp-14536088-0 
org.apache.cocoon.sitemap.node.MatchNode$MatcherContext - Matching: 
expression=generator/*/*/*/source, 
testValue=generator/languages-in-country/country_id/77/source, 
result={3=77, 2=country_id, 1=languages-in-country, 
0=generator/languages-in-country/country_id/77/source}
2012-03-23 14:33:30,598 DEBUG 11202659@qtp-14536088-0 
org.apache.cocoon.sitemap.node.AbstractSitemapNode - 
GenerateNode(src=generators/{map:1}.xml, 
type=url).invoke(/generator/languages-in-country/country_id/77/source)
2012-03-23 14:33:30,598 DEBUG 11202659@qtp-14536088-0 
org.apache.cocoon.pipeline.AbstractPipeline - Adding component 
XMLGenerator(hashCode=29969233 
internalGenerator=URLGenerator(hashCode=19145797 
source=file:/C:/Users/HuttarL/Documents/work/c3/theParent/ethnologue-17-pub/src/main/resources/COB-INF/generators/languages-in-country.xml))

to pipeline [CachingPipeline(hashCode=7335482 components=[])].
2012-03-23 14:33:30,598 DEBUG 11202659@qtp-14536088-0 
org.apache.cocoon.sitemap.node.AbstractSitemapNode - 
SerializeNode(type=xml).invoke(/generator/languages-in-country/country_id/77/source)

So goes there should be a file generators/languages-in-country.xml which 
you said exists.

What does
<map:generate src="generators/languages-in-country.xml" /> gives you if 
you add it directly?

It is really weird since we are talking about

  public static boolean isModifiedResponse() {
         return (Boolean) collectorDataStore.get(KEY_PIPELINE_EXECUTED);
     }

So either collectorDataStore is null (what should not since it gets 
instanced on start) or the result of the get which points to that the 
pipeline-executed infos got lost.

I never saw this behavior before let us see what the direct use test gives.

salu2

-- 
Thorsten Scherler<scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/


Mime
View raw message