db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: compiling XML.java in Java 1.5
Date Thu, 23 Feb 2006 17:45:03 GMT
Army wrote:
> 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?

Yes, thank you very much for you explanations

--Andreas

> Army
> 


Mime
View raw message