In conclusion I don't have any solution for you, but maybe a workaround: Can you use current 2.0 or 2.1 CVS version? At least 2.0.5-dev shall be as stable as 2.0.4. The important difference for you between the two versions is the switch to the interpreted sitemap engine as default one. So you don't depend on the transformation of the sitemap to Java code.
Joerg
Guardiola, Derek (ELS-STL)) wrote:
Here is what I was able to identify using your help below.
Cocoon version 2.0.4 Xalan Java 2.4.D1
Xerces-J 2.3.0 DOM 2.0 DOM.draftlevel 2.0fd Crimson Not Present JAXP 1.1 SAX 2.0
-- Derek Guardiola Elsevier Science
-----Original Message----- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 7:41 PM To: [EMAIL PROTECTED] Subject: Re: sitemap.xls - XSLTFactoryLoader flaw?
Hello Derek,
can you please make sure, that the correct Xalan version is used? You can follow the instructions at http://wiki.cocoondev.org/Wiki.jsp?page=NoMoreDtmIdError or directly http://xml.apache.org/xalan-j/faq.html#environmentcheck.
Guardiola, Derek (ELS-STL)) wrote:
CVS "latest source distribution". I'm not sure exactly which version that
is
distributed but I believe it might be 2.0.4 due to the timestamp.
There are two CVS repositories, one for Cocoon 2.1, a second one for 2.0. Which one do you use? The version is also shown on the welcome or samples pages:
Cocoon 2.0: http://server:port/pathToCocoon/welcome
Cocoon 2.1: http://server:port/pathToCocoon/samples/
Joerg
Derek Guardiola Elsevier Science
-----Original Message----- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 3:56 PM To: [EMAIL PROTECTED] Subject: Re: sitemap.xls - XSLTFactoryLoader flaw?
Hmm, I never I had any problems with the sitemap in such a simple case with nearly all Cocoon versions 2.0.4 and below. In current 2.0 CVS and in 2.1 the sitemap.xsl (=> compiled sitemap) is no longer used as default, but the interpreted sitemap, which as a lot faster.
What's the Cocoon version you use?
Joerg
Guardiola, Derek (ELS-STL)) wrote:
lines 454 of sitemap.xls
// Prepare the pattern for "<xsl:value-of select="@pattern"/>" this.<xsl:value-of select="$matcher-name"/>_expr = this.preparePattern("<xsl:value-of select="$matcher-type"/>",
"<xsl:value-of
select="XSLTFactoryLoader:escapeBraces($factory-loader, @pattern)"/>");
The XSLTFactoryLoader:escapeBraces($factory-loader, @pattern) seems to be causing the site mappings "pattern" to come out blank after the first map:match tag. In the generated file (sitemap_xmap.java) looks like
this..
/** Prepare patterns of PreparableMatchers. */
public void prepareMatchers() throws Exception {
// Prepare the pattern for "hello.html"
this.matcher_N1006D_expr = this.preparePattern("wildcard",
"hello.html");
// Prepare the pattern for "hello2.html"
this.matcher_N1007B_expr = this.preparePattern("wildcard", "");
{SHOULD BE hello2.html}
// Prepare the pattern for "helloCustom.html"
this.matcher_N10089_expr = this.preparePattern("wildcard", "");
{SHOULD BE helloCustom.html}
// Prepare the pattern for "hellocustomgen.html"
this.matcher_N10097_expr = this.preparePattern("wildcard", "");
{SHOULD BE hellocustomgen.html}
}
the xmap file...
<map:pipelines>
<map:pipeline> <map:match pattern="hello.html" type="wildcard">
<map:generate src="test/hello.xml" />
<map:transform src="test/hello.xsl" />
<map:serialize type="html" />
</map:match>
<map:match pattern="hello2.html" type="wildcard"> <map:generate src="test/hello.xml" /> <map:transform src="test/hello.xsl" /> <map:serialize type="html" /> </map:match>
<map:match pattern="helloCustom.html" type="wildcard"> <map:generate type="myGenerator" /> <map:transform src="test/hello.xsl" /> <map:serialize type="html" /> </map:match> <map:match pattern="hellocustomgen.html" type="wildcard"> <map:generate type="myGenerator" /> <map:transform src="test/hello.xsl" /> <map:serialize type="html" /> </map:match> </map:pipeline>
</map:pipelines>
I removed the $factory-loader from the method call and it seems to be working ok now. Is this a bug in the system that might need to be corrected?
XSLTFactoryLoader:escapeBraces(@pattern) is the solution, but i don't want to circumvent anything.
-- Derek Guardiola
