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/

Reply via email to