Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43FDDE09.2070507@sbcglobal.net>
Date: Thu, 23 Feb 2006 08:08:41 -0800
From: Army <qozinx@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: compiling XML.java in Java 1.5
References: <43FD90E3.40409@sun.com>
In-Reply-To: <43FD90E3.40409@sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Andreas Korneliussen wrote:
> I noticed that /java/engine/org/apache/derby/iapi/types/XML.java uses 
> the org.apache.xalan.processor.TransformerFactoryImpl class,and it had 
> the following comments:
> 
> // Note that even though the following has a Xalan
> // package name, it IS part of the JDK 1.4 API, and
> // thus we can compile it without having Xalan in
> // our classpath.
> import org.apache.xalan.processor.TransformerFactoryImpl;

As part of my (currently stalled) work for DERBY-688 I have reorganized the XML 
code in some key ways with the goal of allowing XML.java to build without any 
dependency on Xalan.  Those changes include the movement of all Xalan-related 
dependencies into a separate class that is only loaded at runtime _if_ Xalan is 
in the user's classpath.

I haven't had a chance to complete that work yet because I've been focusing on 
other issues lately--but I do hope to have the changes complete for 10.2.  All 
of that said, let me now answer your two questions:

> The JDK 1.5 API and runtime, does not have this class, (it has been 
> renamed), so I have the following questions:
> 
> 1. Is it necessary to use the impl class, instead of accessing the 
> object through the TransformerFactory interface ?

The current Derby code uses the impl class because it (the impl class) defines 
two methods that are not part of the TransformerFactory API: namely, 
newTemplatesHandler() and newTransformerHandler().  The current code uses those 
classes to process stylesheets to in turn evaluate XPath expressions.

There may be a way to accomplish the same thing indirectly by using other 
methods that are part of the standard API, but I don't know off hand if that's 
the case.  In any event, with my changes for DERBY-688 I've rewritten the XPath 
evaluation code to _not_ use stylesheets and to instead use the lower-level 
Xalan XPath API.  This means that TransformerImpl is no longer required--but of 
course there are other Xalan-specific classes that are necessary, so in the end 
the depenency on Xalan is still there.  But it's been moved out of XML.java into 
another class.

Which leads to the next question:

> 2. At runtime, is there a guarantee that the class is available when 
> using Java 1.5 JDK and using XML functionality ? I noticed the class is 
> also inside xalan.jar, so I guess that this functionality requires this 
> jar file to be included at runtime.

When I originally submitted the XML type and initial operators (DERBY-334) I did 
so with the expectation that the XML type would only work if Xalan was in the 
user's classpath.  That's why the XML tests do not currently run as part of 
derbyall--I didn't want to force anyone running the tests to have to download 
Xalan (or Xerces for that matter) just to run the regression tests.

As for runtime checks, the current code doesn't explicitly check for Xalan, so 
the result will be some sort of ClassNotFound or NoClassDef exception.  That 
might seem silly, but the whole tone of DERBY-334 was that the XML datatype was 
a new type that was not ready for production use--which is why I haven't 
documented it yet (and which is why we've been able to get by so far without 
running nightly regression tests).

With DERBY-688, though, I will be adding better run-time checks to throw more 
user-friendly errors if the required Xalan classes aren't found.  I will also 
reorganize the code, as mentioned above, to remove Xalan dependencies from 
XML.java, which is the base type for XML columns, so that users can operate on 
tables with XML columns even if they don't have Xalan in their classpath, 
assuming they don't actually reference the XML columns (currently that's not 
possible).

Additional changes targeted for DERBY-688 are described in that issue and the 
corresponding spec (which, I admit, needs to be updated).  The intent is that, 
by making these changes, we can make XML an "official" Derby datatype ready for 
production use, and thus we can add it to the documentation.  Most of the 
changes are well on their way to completion, I just have to tie up some loose 
ends and make everything "official".  As I said, I'm hoping to do that for the 
10.2 release...

Does that answer your questions?
Army