cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: sitemap.xls - XSLTFactoryLoader flaw?
Date Sat, 14 Jun 2003 01:36:01 GMT
Everything seems to be ok, though you have updated Xalan and Xerces? 
Cocoon 2.0.4 comes with Xalan 2.3.1 and Xerces 2.0. This /can/ be 
reason, but is not needed to be. I thought more the other way around 
(using the Xalan delivered with Sun JDK 1.4).

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:joerg.heinicke@gmx.de]
> Sent: Wednesday, June 11, 2003 7:41 PM
> To: cocoon-dev@xml.apache.org
> 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:joerg.heinicke@gmx.de]
>>Sent: Tuesday, June 10, 2003 3:56 PM
>>To: cocoon-dev@xml.apache.org
>>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


Mime
View raw message