ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject RE: [Solution] ANT/TRAX/REDIRECT
Date Fri, 10 Aug 2001 17:33:16 GMT

Thanks for your report, I have fixed this at home and will commit soon to
Ant 1.4 (not beta1 of course) to also workaround some issues in Xalan that
are at the moment being under fixing in Xalan 2.2 code.

Did you open a bug for this one ? If not please do so that you will be
notified and able to test the patch by taking a nightly build.

You can see my mail in xalan-dev here:

Thanks again.

 Stephane Bailliez 
 Software Engineer, Paris - France 
 iMediation - 
 Disclaimer: All the opinions expressed above are mine and not those from my

> -----Original Message-----
> From: Michael J. Hudson []
> Sent: Friday, August 10, 2001 7:07 PM
> To:
> Subject: [Solution] ANT/TRAX/REDIRECT
> Woohoo!!
> I think I, Code Detective M. J. Hudson broke the case of the "The Ant
> Who Left No TRAX To Redirect"... :) I kill me... 
> Anyway... for those who don't remember my email a couple of days ago,
> let me refresh all on the problem I was having.  Actually, I ended
> up with two bugs/problems... but let me tackle the BIG one first.
> Both bugs ended up with possible bugs in ANT.
> Simply put... the following are the requirements that I have found
> to replicate the problem:
> 1) Platform:  Unfortunately, this seems to be a platform-oriented
> problem.  Things worked fine on a Linux-box... but broke down on my
> Windows NT box.  I'm not sure if this will happen on ALL Windows
> machines, but I think it will.
> 2) XSLT file that uses the 'redirect' extension with a 
> relative address
> for the filename.  If you remember, the 'redirect' element is not a
> XSLT standard... but an extension that XALAN supports (as 
> well as other
> processors as well) that allows the user to redirect processing output
> to a number of other files.  In this case, the output was redirected
> to a file defined by a relative file address.
> 3) An ANT build.xml that has a target to process the above XSLT file
> using the TRAX processor.  Simply put... use the <style> element with
> the attribute 'processor' having a value of "trax".  TRAX is the new
> standard transformation API that XALAN will be using while eventually
> getting rid of its older API.
> If you run that build file against that XSTL file on a Windows NT box,
> you should get the error I got... TransformerException.  And you'll  
> notice the line of the XSTL file where it stopped is where your
> 'redirect'
> extension is called.  
> In any case... the reason for this problem is the ''
> code in ANT.  ANT uses this code as a proxy to the 
> javax.xml.transformer
> stuff.  HOWEVER, before it sends any filenames to the transformer, it
> first appends the filenames with "file:".  THIS, my friends, is what
> was causing the problem.  Essentially, the Windows-box was getting the
> full absolute address of the file mentioned in the 'redirect' element,
> by prepending the relative address with the address of the input 
> XML or XSLT files.  This address was then prepended with the "file:"
> prefix.  When Windows processed this... it strips the "file" prefix
> but doesn't strip the colon itself.  The reason... is that Windows 
> recognizes "file:///" as a valid URL prefix, not just "file:".  So,
> I went into the ANT code, replaced "file:" with "file:///",
> recompiled, rejarred, and WALLA, everything worked.
> That's not all folks... after that fiasco... I ran into another 
> problem.  I use a temporary directory to temporarily put chunks of
> processed data until the end of the XSLT file where I either do
> some more processing or re-package chunks of data together and
> put it somewhere more perminent.  Thus, in my <style> element,
> I specify my destination directory AT this temporary directory.
> At the beginning of each 'target', I would delete everything in
> this temporary directory... so as not to confuse old processed
> files with new ones.  The problem is... the old 'target' for
> some reason still had resource handles to the old processed
> files and thus the deletion of the directory failed because
> Windows doesn't let one mess with a file that still has an
> open handle to it.  Sooo... the problem there was in the
> code AS WELL...  a FileOutputStream is created
> as a parameter to the transformer... but never CLOSED.  So, did
> some simple finaggling and created it before the transform,
> passed it to the transformer, and after the transformer finished,
> it then closed it.  And after recompiling and rejarring...
> WALLA... that worked too.
> So... in the end... I found what I believe to be two bugs in the
> file.  They seem to be platform-dependent... because
> it happened consistently on two different NT-boxes... yet worked fine
> on a Linux-box.  
> And that's that... another case closed by Code Detective, M. 
> J. Hudson!
> Another "byte" out of crime... god, that was awful... I apologize, but
> cheese is good! :)
> -------------------------------------
> Michael J. Hudson
> Software/Framework Engineer
> cell-phone: 703.362.8039
> voice-mail: 703.827.0638 ext. 4786
> fax: 703.734.0987
> Blueprint Technologies
> "Great software starts with great architecture"

View raw message