forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Updating cocoon (was Re: [jira] Commented: (FOR-1083) switch to Cocoon 2.1.x)
Date Thu, 21 Aug 2008 06:19:14 GMT
David Crossley wrote:
> Thorsten Scherler wrote:
> > David Crossley wrote:
> > > Thorsten Scherler wrote:
> > > > David Crossley wrote:
> > > > >
> > > > > I did not need to do anything with that project symbols ent file.
> > > > 
> > > > Hmm, I always get error because of the ent files (I tried as well with
> > > > new seed).
> > 
> > Hmm, you have not tried the branch, or?
> That is correct. I was reporting that mine was working.
> You got to commit all your stuff before i could. So i now
> need to svn up and follow on.
> > If  you do you will see the
> > problem, but I reckon you will know right away how to fix it.
>  [ snip]
> > Actually the resolver issue may be caused by updating
> > excalibur-sourceresolve-2.2.3.jar but that needs fixing after all if we
> > want to be able to constantly update cocoon.
> That is why i was progressively updating the jars,
> getting something that works with minimal changes.
> I now reverted mine and did 'svn up'. With yours i
> now see the problem you describe.
> It is a big issue. The first error can be worked around
> by copying that symbols-core-v10.ent to main/webapp
> However, after that the xml framework is busted and every
> occasion that a DTD needs resolving, it goes to
> and other websites, rather than local copies.
> I will go back to what i had, and come forward to find
> which new jar caused it.

I found the problem. It was the Cocoon configuration file.

In my working setup, i had kept our old configuration
by copying the content of our main/webapp/WEB-INF/xconf/forrest-core.xconf
into main/webapp/WEB-INF/cocoon.xconf (see FOR-955).

In your setup, i am not clear where you got the content from.
Perhaps it was direct from the Cocoon-2.1 cocoon.xconf file
or from its build/webapp/WEB-INF/cocoon.xconf which is produced
after processing block configurations.

So it has some different parameters to ours, e.g.
the "catalog" parameter for "entity-resolver".
Hence the error described above.

It also uses the "Cocoon properties" system to set some values, e.g.
<parameter name="freememory" value="${store-janitor.freememory}"/>
In the Cocoon-2.1 SVN those values come from
A while ago i added that ability to Forrest (FOR-917)
so we should now be able to set up something similar.

I will work on this aspect of our upgrade.
It is a big task. We need to find some way to make
it easy to keep the configuration synchronised with
that at Cocoon-2.1 and its blocks config, each time
we upgrade our packaged Cocoon.


View raw message