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 a
> > > > 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 apache.org
> 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
src/webapp/WEB-INF/properties/core.properties
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.
-David
