cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: pipelineComponent scope troubles
Date Wed, 12 Sep 2007 15:23:19 GMT
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
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
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

> Well, standard cocoon blocks mounted by DispatcherServlet into a standard cocoon-webapp
> 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
DispatcherServlet and collaborating classes.

> The stacktrace of the first request to standard Cocoon trunk is this:


> Caused by: java.lang.NullPointerException
> 	at java.util.HashMap.putAll(
> 	at org.apache.cocoon.el.impl.objectmodel.ObjectModelImpl.setParent(
> 	at
> org.apache.cocoon.components.pipeline.spring.PipelineComponentScope.get(

This stack trace is when ObjectModel is in pipelineComponent scope. You said that after setting
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
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

View raw message