Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xml.apache.org
Message-ID: <3AFC6E09.8BB8598E@sun.com>
Date: Fri, 11 May 2001 15:56:09 -0700
From: Edwin Goei <edwingo@sun.com>
MIME-Version: 1.0
To: general@xml.apache.org
CC: pmc@xml.apache.org, Costin Manolache <Costin.Manolache@eng.sun.com>,
        Davanum Srinivas <dims@yahoo.com>
Subject: Re: XMLReaderFactory/SAXParserFactory/DocumentBuilderFactory does not
 use getContextClassLoader
References: <20010511190047.24722.qmail@web110.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Davanum Srinivas wrote:
> 
> XMLReaderFactory/SAXParserFactory/DocumentBuilderFactory all use Class.forName() directly. This is
> going to cause problems with JDK1.4 because JAXP classes are packaged with the JRE itself.
> Switching to another parser using System Property or jaxp.properties will fail. Please correct me
> if am wrong.

Yes, this is true for the code that is bundled in JDK1.4 beta itself
because those classes take priority over any classes defined anywhere
else (like on your classpath).  The bugs you list have already been
fixed for JDK1.4 beta-refresh (after beta).  Unfortunately, the fix for
all of these problems won't be out until then.

For the API portions of JAXP 1.1, which contains these packages:
    1) javax.xml.parsers
    2) javax.xml.transform
    3) org.xml.sax.*
    4) org.w3c.dom.*

there is code in #1, #2, and #3 that is classloader sensitive.  They are
all factory classes.  The fixes for #3 require changes to SAX code.

In addition, there may be code in the implementation that has this same
problem.  The implementation in JDK1.4 is based on crimson 1.1.x and
xalan-j 2.x.  The fixes for crimson have already been made.  I believe
costin is working on the xalan-j 2.x changes.

> 
> We can fix the problem by trying Thread.currentThread().getContextClassLoader() to load the class
> and fall back to Class.forName() if it fails. This is the approach taken by Xalan's extension
> loading mechanism. Right Scott?

I think your basic idea is sound.  It might be a little more complicated
than that if you want the code to run on JDK 1.1.x VMs and there are
additional constraints if you want the code to run as an applet in IE 5
or NS 4.7 VMs.  These JVMs are not Java 2 compatible and thus do not
have the getContextClassLoader() method and the IE 5 VM in particular
does early symbol binding so some care must be taken in how to fallback
to using the bootstrap classloader.  I have fixed the JAXP API classes
to get it to work in all these cases.

> 
> What can we do? Any suggestions? Beta for JDK1.4 is not too far...

If you have to use an early version of JDK1.4, one workaround might be
to use the -Xbootclasspath:bootclasspath command line option.

-Edwin

PS: I'll be gone for about a week.

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org