Return-Path: <mhudson@blueprinttech.com>
Mailing-List: contact xalan-j-users-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list xalan-j-users@xml.apache.org
Received: (qmail 56147 invoked from network); 10 Aug 2001 17:10:34 -0000
Received: from unknown (HELO gatekeeper.blueprinttech.com) (63.142.119.68)
  by h31.sny.collab.net with SMTP; 10 Aug 2001 17:10:34 -0000
Received: from blueprinttech.com (64-48-91-69.customer.algx.net [64.48.91.69])
	by gatekeeper.blueprinttech.com (8.8.7/8.8.7) with ESMTP id NAA27904
	for <xalan-j-users@xml.apache.org>; Fri, 10 Aug 2001 13:08:34 -0400
Message-ID: <3B7414F8.22A01ED2@blueprinttech.com>
Date: Fri, 10 Aug 2001 13:08:08 -0400
From: "Michael J. Hudson" <mhudson@blueprinttech.com>
Reply-To: mhudson@blueprinttech.com
Organization: Blueprint Technologies, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: xalan-j-users@xml.apache.org
Subject: [Solution] ANT/TRAX/REDIRECT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N


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.. though since this
involves
XALAN as well, I thought I should send this to this list as well...

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 'TraxLiaison.java'
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
TraxLiaison.java 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
TRAXLiaison.java 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
mhudson@blueprinttech.com

cell-phone: 703.362.8039
voice-mail: 703.827.0638 ext. 4786
fax: 703.734.0987

Blueprint Technologies
"Great software starts with great architecture"
http://www.blueprinttech.com