ant 1.8 feature or bug? change how xslt task uses 'classpathref' to load extension classes

[Will Milspec <wi...@gmail.com>]

Hi all,

I came across a problem when we upgraded from ant 1.7 to 1.8.0 and 1.8.1. I
originally though it was a xalan issue so posted to the xalan list.  I since
found that the 'xslt' task behaved differently between 1.7 and 1.8.

I've included  below my 'solved' followup email to the xalan list.

Could someone weigh in whether a) this is a feature or a bug b) had we
misused the 'classpathref' attribute, i.e. did it happen to work by accident

thanks in advance,

will


SOLVED: As a follow-up to my earlier email "extension problem", I've found
the cause of said problem: how ant 1.8 uses the "xslt" task's 'classpathref'
attribute  to load extension classes.

To recap:
============
* our ant build script used the xslt task to process xml files
* the xsl file used xalan's extension mechanism to call a custom class to
write out unicode characters to the output file
* in ant 1.7, the combination of build.xml and .xsl worked fine
* in ant 1.8.0 ant 1.8.1, xalan threw this exception:


    [xslt] /home/myhome/projects/pe_
mainline4/pe/src/xsl/literals/gen_java.xsl:84:41: Fatal Error!
java.lang.NoSuchMethodException: For extension function, could not find
method
org.apache.xml.dtm.ref.DTMNodeIterator.formatUnicode([ExpressionContext,] ).
Cause: java.lang.NoSuchMethodException: For extension function, could not
find method
org.apache.xml.dtm.ref.DTMNodeIterator.formatUnicode([ExpressionContext,] ).


Cause:
==========
It turns out:
-Ant 1.7 uses the 'classpathref' attribute of the 'xslt' style task to load
the custom/extension class
-Ant 1.8 does not use 'classpathref' in the same way. Xalan could not load
the custom class , even though our build.xml had the value for
'classpathref'

I could toggle off/on 'NoSuchMethod' error by calling the xalan.xslt.Process
from the command line and adding/not-adding the path-to-my-extension-class
to my classpath.

Workaround
===========
I haven't analyzed the ant code yet to find/fix/grok the 1.8 changes which
caused the change, but have the following workaround:

* I compiled-and-jarred the 'unicode utility' class and put the .jar file in
$ANT_HOME/lib. The XSLT task correctly found the 'extension' class

* I looked into calling the xalan.xslt.Process class directly (i.e. with the
-IN,-OUT,etc. arguments) and explicitly setting the classpath, but need the
ability to process multiple files 'in one shot'.


Ant build.xml fragment
============
   <xslt basedir="${literals.dir}/xml"
          extension=".log"
          destdir="${literals.dir}"
          style="${literals.xsl.dir}/
gen_java.xsl"
          includes="*.xml"
          classpathref="build.classpath"  <--Build.classpath pointed to
classpath that included our compiled classes
          >

xslt fragment
==================

<xsl:stylesheet version="1.0" xmlns:xsl="
http://www.w3.org/1999/XSL/Transform"
   xmlns:redirect="http://xml.apache.org/xalan/redirect"
   xmlns:escape="xalan://com.mycompany.util.xml.UnicodeEncodeUtil"

   extension-element-prefixes="redirect escape"
   >

Hope this helps someone

Re: ant 1.8 feature or bug? change how xslt task uses 'classpathref' to load extension classes

[Stefan Bodewig <bo...@apache.org>]

On 2010-08-04, Will Milspec wrote:

> I came across a problem when we upgraded from ant 1.7 to 1.8.0 and 1.8.1. I
> originally though it was a xalan issue so posted to the xalan list.  I since
> found that the 'xslt' task behaved differently between 1.7 and 1.8.

> I've included  below my 'solved' followup email to the xalan list.

> Could someone weigh in whether a) this is a feature or a bug

A bug

https://issues.apache.org/bugzilla/show_bug.cgi?id=49271

Re-reading it reminded my that Jesse objected to the "fix" and that it
should be fixed more properly.  Which I'm going to do now, so thanks for
the reminder 8-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org