I can reproduce the same error that Gump was reporting. I've been trying to
debug it by running Xalan by hand on the properties.xsl and foproperties.xml
that are failing and tracing that. I'm getting some inconsistent results
however. Every failure is from a recursive call to the "propclass" template
as seen in Gump, but I can get it to fail at different points in the XML
source it's processing.
I've changed the template to this:
<xsl:template name="propclass">
<xsl:param name="prop" select="."/>
<!-- <xsl:message>PropName: <xsl:value-of
select="$prop/name"/></xsl:message> -->
<xsl:variable name="prop-class-var">
<xsl:choose>
<xsl:when test="$prop/datatype">
<xsl:value-of select="$prop/datatype"/><xsl:text>Property</xsl:text>
</xsl:when>
<xsl:when test="$prop/use-generic[@ispropclass='true']">
<xsl:value-of select="$prop/use-generic"/>
</xsl:when>
<xsl:when test="$prop/use-generic">
<!-- If no datatype child, then the prop must use the same datatype as
its template. -->
<xsl:call-template name="propclass">
<xsl:with-param name="prop"
select="key('genericref', $prop/use-generic)"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<!-- ERROR -->
<xsl:message terminate="yes">
No datatype found for property: <xsl:value-of select="name(.)"/>
</xsl:message>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:message>PropClass: <xsl:value-of
select="$prop-class-var"/></xsl:message>
<xsl:message>PropName: <xsl:value-of select="$prop/name"/></xsl:message>
<xsl:value-of select="$prop-class-var"/>
</xsl:template>
Running Xalan with -TT, this fails on the property[@name='padding-before']
element in the source. However if I comment out the PropName message at the
end and uncomment the first one at the beginning of my modified template,
then it fails in a recursive propclass call on the
property[@name='conditional-length-template'].
My suspicion is that the nodes returned by the key function used in the
recursive call are somehow corrupted. I'm have no clue why it would error
out in different places depending on if I write a message out before or
after this template does its work. I don't have time to dig into this any
more today however. Hopefully someone on the Xalan team will be able to look
into this.
-Kelly
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 11:48 AM
> To: Kelly Campbell
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Gump xalan2 failures
>
>
>
> I checked it out fresh... so I dunno. I will try again in a bit.
>
> -scott
>
>
>
>
>
>
> Kelly
>
> Campbell To:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> <camk@channel cc:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> point.com> Subject: RE:
> Gump xalan2 failures
>
>
> 06/18/01
>
> 03:17 PM
>
>
>
>
>
>
>
>
>
> Scott,
>
> Is it possible you have an older version of FOP checked out
> and didn't do a
> "build clean"? That's about the only thing I can think of
> that might be
> causing that ambiguous class error. I will try a clean build
> using Xalan2
> from CVS and see what happens.
>
> -Kelly
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, June 17, 2001 4:38 PM
>
> > 3) I can't seem to build xml-fop:
> > compile:
> > Compiling the sources
> > [javac] Compiling 133 source files to E:\xml-fop\build\classes
> > [javac]
> > E:\xml-fop\build\src\org\apache\fop\image\ImageArea.java:64:
> > Ambiguo
> > us class: org.apache.fop.layout.InlineArea and
> > org.apache.fop.layout.inline.Inli
> > neArea
> > [javac] public class ImageArea extends InlineArea {
> > [javac] ^
> > [javac] E:
> > \xml-fop\build\src\org\apache\fop\render\awt\AWTRenderer.java:26:
> > Package org.apache.batik.swing.svg not found in import.
> > [javac] import org.apache.batik.swing.svg.*;
> > [javac] ^
> > [javac] E:
> > \xml-fop\build\src\org\apache\fop\render\awt\AWTRenderer.java:27:
> > Package org.apache.batik.swing.gvt not found in import.
> > [javac] import org.apache.batik.swing.gvt.*;
> > [javac] ^
> > Terminate batch job (Y/N)? y
> > I assume I'm doing something dumb... perhaps the fop folks
> can help?
> > build codegen seems to succeed, but it is rather too fast, so
> > I fear it's
> > not doing anything.
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
