Return-Path: 
 <cocoon-dev-return-43674-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 23342 invoked by uid 500); 16 Jun 2003 15:57:16 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 23329 invoked from network); 16 Jun 2003 15:57:16 -0000
Received: from mail-relay5.elsevier.com (63.125.147.41)
  by daedalus.apache.org with SMTP; 16 Jun 2003 15:57:16 -0000
Received: from elsstls17525.elsevier.com (unverified) by
 MAIL-RELAY5.elsevier.com
 (Content Technologies SMTPRS 4.3.1) with ESMTP id
 <T62dca7e91e3f7d93295cc@MAIL-RELAY5.elsevier.com> for
 <cocoon-dev@xml.apache.org>;
 Mon, 16 Jun 2003 10:53:06 -0700
Received: by elsstls17525.elsevier.com with Internet Mail Service
 (5.5.2655.55)
	id <M1S9B8QP>; Mon, 16 Jun 2003 10:56:56 -0500
Message-ID: 
 <9C74C403F6464545B64C250FFF6A1AA70775488C@elsstlvexch01.inside.mosby.com>
From: "Guardiola, Derek (ELS-STL))" <D.Guardiola@Elsevier.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: sitemap.xls - XSLTFactoryLoader flaw?
Date: Mon, 16 Jun 2003 10:51:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Joerg,
	I found the problem, it was related to the versioning of either
XALAN or XERCES.  My versions were newer than those that came with Cocoon
2.0.4.  I specifically placed the jars that came with Cocoon in the
containiner and it works properly now.

I was testing on Tomcat 4.1.  I had replaced the xerces jars in the
"<tomcat_home>common/endorsed" with the ones in the cocoon distribution.
They had a newer timestamp (3/19/03).  Then it appears as if the custom
build had also created a different xalan version that those that came with
the cocoon.  So I replaced the xalan jars in my webapp/WEB-INF/lib folders
with the originals in the cocoon pacakge.  

Seems to working normally.  The Cocoon developement team might want to keep
an eye on this as the newer versions of Xalan/Xerces come around.  This
might be a small blip on the radar for things to come.

Thanks for the help.

--
Derek Guardiola
Elsevier Science


-----Original Message-----
From: Joerg Heinicke [mailto:joerg.heinicke@gmx.de]
Sent: Friday, June 13, 2003 8:36 PM
To: cocoon-dev@xml.apache.org
Subject: Re: sitemap.xls - XSLTFactoryLoader flaw?


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